Кто работает с микросервисами - есть вопросы
Добавили в таблицу поле адрес, обновили апи, хотим показать адрес в UI. Как без "синхронизации"?
Тебепонятие "контракта" или "интерфейса" о чем-нибудь говорит?
Синхронизация - это вообще о другом. Если бы ты пользовался бы принятой в ИТ терминологией, то странных вопрособ было бы гораздо меньше. Синхронизация (информатика)
Ну может тогда расскажете какая ORM генерит интерфейсы.
Без понятия. Подозреваю, что никакая, т.к. эта задача не имеет смысла.
Ну расскажите тогда как называется то что я хочу принятой в ИТ терминологией
Это называется "контрактом" или "интерфейсом".
Подозреваю, что никакая, т.к. эта задача не имеет смысла.
Ну так о чём и говорю, с одной стороны у меня классы для базы, с другой классы для АПИ, с третьей для UI. и все их нужно ...
Это называется "контрактом"
Как то еще ни разу не слышал - а ну ка сделай мне одинаковые контракты данных. 
Кроме как с WCF ничего больше и не попалось. И очень сомневаюсь что бы кто то меня понял с таким выражопиваем.
Ну так о чём и говорю, с одной стороны у меня классы для базы, с другой классы для АПИ, с третьей для UI. и все их нужно ...
И все их нужно... ничего :)
Есть классическая слоеная архитектура, в которой слои связаны между собой некими интерфейсами. Если в твоем случае это:
1) UI level
2) Application level
3) DAL
то UI level вообще ничего не должен знать о DAL. Ни о структуре таблиц, ни даже о существовании DAL.
Ты пытаешься сделать какую-то неподдерживаемую хренотень.
Как то еще ни разу не слышал - а ну ка сделай мне одинаковые контракты данных.
Что значит одинаковые контракты данных? И зачем это вообще надо?
Кроме как с WCF ничего больше и не попалось. И очень сомневаюсь что бы кто то меня понял с таким выражопиваем.
Добавили в таблицу поле адрес, обновили апи, хотим показать адрес в UI. Как без "синхронизации"?
Никак. Но Программист прав. Транспортные классы ДТО не обязаны соответствовать ни базым данных ни Ентити-классам, связанным с базами данных или другими иточниками данных. Мы храним одни данные в одном виде, передаем возможно в другоm. Передаем то, что или нужно клиенту или мы считаем, что ТАК нужно клиенту
Алекс, вы путаете теплое с мягким.
Ну добавили в апи вашего микросервиса еще одно поле/перешли на новую версию интерфейса.
Что вы собрались тут синхронизировать? Классы DTO? Так уй и бэкэнд на разных языках написаны.
Уй - это такой же консьюмер вашего апи, как и все остальные. Естественно разработчик уя добавит это поле в свой DTO класс, или что у него там заместо оного.
Возможно он сгенерирует новые DTO классы из описания автоматически. А может и ручками добавит.
Вы думаете о софте как об окошках с кнопочками и текстовыми полями, а надо как о потоках данных.
Знаете как в Германии информатику называют? EDV - электронная обработка данных :-)
Есть классическая слоеная архитектура, в которой слои связаны между собой некими интерфейсами.
Не для веба. На вебе клиент и сервер это 2 независимых приложения. Общение через ХТТП-запрос, фактически через текстовой файл. Ни одна из сторон не имеет ни малейшего представления о технологиях другой. Нет ни интерфейсов ни слоев.
Фактически сервер, принимая запрос и (если нужно) десериализуя обьект, инстанцирует готовый пустой обьект, такого класса, который он считает нужным. И начинает парсить запрос, пытаясь инициализировать и заполнить этот обьект. Разумеется в запросе никаких обьектов нет. Есть голый текст. И разумеется, если другая сторона внезапно прислала какую то хрень, то может произойти разное. Может быть сгенерирована ощибка на базе валидации готового обьекта. А может получится обьект с неицилизированными пропертями.
Что вы собрались тут синхронизировать? Классы DTO?
Да. Если сервер шлет на одно поле больше, то клиент начнет использовать это поле только после "синхронизации". Если сервер удалил поле из обьекта, то у клиента без "синхронизации" это поле останется просто пустым. С соответствующими последствиямi
Не для веба.
Возможно веб - это другой мир, но я почему-то сомневаюсь :D
На вебе клиент и сервер это 2 независимых приложения.
Ну так такое и не в вебе сплошь и рядом встречается. То, что это 2 независимых приложения не обязатетельно должно отменять слои ;)
Общение через ХТТП-запрос, фактически через текстовой файл. Ни одна из сторон не имеет ни малейшего представления о технологиях другой. Нет ни интерфейсов ни слоев.
А ты посмотри на это несколько иначе. Чем ХТТП запрос отличается от вызова какой-либо функции? Чем содержимое файла отличается от ДТО? Набор ХТТП запросов, а также входные и выходные данные - это и есть контракт/интерфейс между фронт- и бэкэндом.
Собственно говоря, браузер всего лишь занимается рендером UI. Какая разница, по какой технологии рендерить контролы web, WinForms, Qt, WPF итд?
То, что это 2 независимых приложения не обязатетельно должно отменять слои
Слои есть внутри самих приложений. Интерфейсы позволяют контрактами договорится внутри приложения о имплементации классов и принудить вторую сторону выполнить принятый договор. Но не между приложениями. Приложение получило какую то текстовую хрень и пытается по собственному разумению ее десериализировать. И ничего не знает о том, что другая сторона уже весь класс перестроила.
Чем ХТТП запрос отличается от вызова какой-либо функции?
Отсутствием синтаксической проверки во время программирования.
Набор ХТТП запросов, а также входные и выходные данные - это и есть контракт/интерфейс между фронт- и бэкэндом.
Интерфейс принуждает программиста править классы, имплементирующие измененные интерфейсы. А вот в вебе пришла какая то хрень и хорошо, если сервер выкинет ошибку о невозможности влепить текстовые данные в числовое поле.Фронденщики ДТО изменили втихаря. Упс. А может просто игнорировать отсутствующее поле, если на нем валидатия не висит.
Собственно говоря, браузер всего лишь занимается рендером UI. Какая разница, по какой технологии рендерить контролы web, WinForms, Qt, WPF итд?
Немного не так. До браузера все эти технологии не доходят. Только ява-скрипт и хтмл с цсс. Но дело не в этом. Дело в том, что обмен данными между бэком и фронтом осуществляется по устному договору, который не проверяется синтаксически. Типа фронтэндщик коворит "зуб даю" и этому приходится верить
Интерфейсы позволяют контрактами договорится внутри приложения о имплементации классов и принудить вторую сторону выполнить принятый договор. Но не между приложениями.
Есть несколько способов для Inter Process Communication. Собственно говоря, возьми любую коммуникацию по TCP - там все тоже самое. О контракте, которым должны соответствовать данные договариваются клиент и сервер. Иписание какого-либо протокола в PDF - это тоже контракт. Ну и в общем случае интерфейс не может принудить выполнять какой-либо договор. Интерфейс - это декларация, т.е. объявление всем контагентам, что какой-то объект соответствует какому-либо контракту, но ты не может а) заставить контрагента подчиняться этому контракту и б) нельзя гарантировать, что объект на 100% делает то, что декларируется.
Приложение получило какую то текстовую хрень и пытается по собственному разумению ее десериализировать. И ничего не знает о том, что другая сторона уже весь класс перестроила.
Если приложение ожидает данные по одному контракту, а получает другой, то оно просто сообщает об ошибке и все.
Просто разработчики должны договориться и использовать один контракт.
Отсутствием синтаксической проверки во время программирования.
Ну вот WCF дает такую проверку. И что? Это теперь не HTTP? :D Договоренности же не обязательно должны проверяться на стадии компилирования.
Интерфейс принуждает программиста править классы, имплементирующие измененные интерфейсы.
Интерфест - это просто форма документации, соответствие которой можно проверить на этапе компилорования.
А вот в вебе пришла какая то хрень и хорошо, если сервер выкинет ошибку о невозможности влепить текстовые данные в числовое поле.Фронденщики ДТО изменили втихаря. Упс. А может просто игнорировать отсутствующее поле, если на нем валидатия не висит.
Ну так в таком случае пронтэдщики встречаются в переговорке с бэкэндщиками и говорят "мы работаем по контрату от 1.1.2000", а другие им от вечают "а мы по контракту от 1.2.2020" и на этом разговор можно завершить и перейти к обсуждению того, какой контракт более правильный и, может быть, сделать новый контракт, который устроит всех.
Дело в том, что обмен данными между бэком и фронтом осуществляется по устному договору, который не проверяется синтаксически. Типа фронтэндщик коворит "зуб даю" и этому приходится верить
Ну это уже вопрос реализации :) Никто же не мешает запикнуть версию контракта в DTO ;)
то UI level вообще ничего не должен знать о DAL
А кто говорил что он должен знать?
Вот расскажите, какие будут шаги если мне нужно грубо говоря "показать" базу в приложении.
1. Генерируем классы данных из таблиц базы
2.
...
И теперь тоже самое, но через микросервис 
И зачем это вообще надо?
Уже спрашивал - Ну расскажите тогда как называется то что я хочу принятой в ИТ терминологией
объект класса это участок памяти, занятый по определенным правилам. То, что передает нттп запрос это серилизация. Это не объект. Объект в определенной среде надо заново инстанцировать и инициализировать из информации, которую передает нттп запрос. А сам нттп запрос это просто текст. Этот текст можно после получения интерпретировать. И файлов там быть по определению не может. Потому что файл это юнит файловой системы. По получении запроса и на основании инфы в запросе он может быть создан на конкретном компе в конкретной файловой системе.