Здравствуйте, MaximVK, Вы писали:

MVK> Теперь про обучение BE. Подход, который ты предлагаешь, со временем в целях оптимизации, потребует частичного заполнения бизнес-сущностей. Что, в свою очередь, повлечет необходимость добавления методов вида IsOrderNameSpecified(), IsOrderDateCreatedSpecified() и т.д. для каждого поля BE. Далее, код, который использует BE должен будет предварительно вызвать этот метод, чтобы убедиться, что поле, которое он собирается использовать, определено. Также посыпятся методы BE которые используют внутренние поля, например методы вида GetUserFullName(), который из FirstName и LastName делает полное имя, т.к. BE не должна уметь сама себя загружать то от таких методов придется или избавиться, или сделать проверочный метод, или вышвыривать исключение. Частично заполненые объекты требует крайне внимательного с ними обращения и являются потенциальным источником большого количества трудно обнаружимых ошибок.

Это всё твои домыслы и ничего более. Никто никаких методов без крайней необходимости писать не будет. Необходимость проверки полей мне не будет нужна по одной простой причине. Если я не включаю данные в объект, то логично предположить, что я не собираюсь их использовать. Неожиданный поворот, не правда ли

MVK>Пример, который я привел — это DTO которое используется для отображений данных в гриде.

После вот этого утверждения дискуссию можно было бы закончить. То, что ты называешь DTO — это вовсе не DTO, это как раз и есть то, о чём я говорю. У DTO одно единственное предназначение — transfer. У тебя же объект, который максимально подогнан не под transfer, а под отображение в гриде. Это нормально, это и есть BE, отражающая твою объектную модель, модель, используемую в UI. Или у UI приложения не может быть своей объектной модели?

В общем, ты теперь сам должен определиться. Либо ты продолжаешь утвеждать, что это DTO, но соглашаешься с тем, что ты грубо нарушил заветы паттерна, либо признать, что на лицо элементарная путаница в терминологии. Выбирать тебе

MVK>Ты предлагаешь мне проектировать мои BE, так чтобы их было удобно изображать на гриде? Но это две совершенно разные задачи. Business entities — суть контейнеры для данных описывающие предметную область, язык на котором общаются другие компоненты системы. Вероятность изменения BE значительно ниже, чем вероятность изменения требований о представлении данных клиентами, т.к. первые отражают значительно более инертную предметную область(я уже молчу про индустриальные стандарты, которые тоже находят отражения в BE).

Давай попробуем разобраться без догм и фанатизма. Что такое контейнеры для данных, описывающие предметную область или что угодно другое? Это объектная модель, на которой строится функциональность приложения. Верно? Верно. У клиентского UI приложения может быть своя объектная модель, на которой строится фукнциональность UI приложения? Может. Тогда какая по сути принципиальная разница между объетной моделью UI приложения и BE, которые есть контейнеры данных, описывающие предметную область? Совершенно верно, ни-ка-кой. И то, и другое суть контейнеры, предназначение которых обеспечить совместно с логикой приложения работу системы в соответствии с функциональными требованиями.

Здравствуйте, akasoft, Вы писали:

A>Гм. А как оценивается тобою вот этот вариант? Он как стыкуется с БО, используемыми сервером?

С этим сервисом я детально не разбирался.

Здравствуйте, akasoft, Вы писали:

A>Полагаю, тут немалое влияние оказало и то, кто и как развивал проект. Квалификация и опыт самые разные.

Это понятно. Я ни в коем случае никого не осуждаю и не виню. Хотя бы потому, что среди виновных моё место было бы не последним, гы-гы. Но назвать идеальным дизайн сайта в целом и януса в частности я не могу и как пример стройности архитектуры приводить не собираюсь.

A>И почему, собственно, БО в Янусе должны быть 1-к-одному, как на сервере? Ведь это же оффлайн-клиент всё-таки, он обязан долговременно и функционально работать сам по себе.

Дело не в одинаковости моделей. Мы здесь спорим не об этом. Мы пытаемся понять необходимость DTO для переноса данных из одного приложения в другое.

Здравствуйте, IT, Вы писали:

IT>После вот этого утверждения дискуссию можно было бы закончить. То, что ты называешь DTO — это вовсе не DTO, это как раз и есть то, о чём я говорю. У DTO одно единственное предназначение — transfer. У тебя же объект, который максимально подогнан не под transfer, а под отображение в гриде. Это нормально, это и есть BE, отражающая твою объектную модель, модель, используемую в UI. Или у UI приложения не может быть своей объектной модели?

Вот в данном случае не соглашусь. Основная цель DTO, как и всего презентационного слоя является изоляция логики сервера от логики клиента. DTO — является частью презентационного слоя. Эффективная пересылка — это уже другая цель. Какая там логика на клиенте — серверу неизвестно и должно быть по барабану. Это в принципе не должно быть известно и DTO и презентационному слою. Его первичная цель предоставить эффективный доступ к функциональности сервера для всех клиентов.
Идеальным решением было бы связка XQuery/XML/Schema, и отношение к DTO не как объекту, а как набору данных. Тогда каждый клиент мог бы заказать не только какие с какими условиями и в какой последовательности объекты ему нужны. Но и в каком виде. К сожалению это решение достаточно сложное и много проблем при реализации.

Здравствуйте, IT, Вы писали:

IT>Это всё твои домыслы и ничего более. Никто никаких методов без крайней необходимости писать не будет. Необходимость проверки полей мне не будет нужна по одной простой причине. Если я не включаю данные в объект, то логично предположить, что я не собираюсь их использовать. Неожиданный поворот, не правда ли

Отнюдь, вполне ожидаемый , т.к. именно эта аргументация приводиться чтобы оправдать такой подход. Неожиданность в другом — я не ожидал услышать такой, прямо скажем, слабой аргументации от тебя. Для небольшого проекта или прототипирования — это вполне разумный подход, который экономит время, а количество кода, сотрудников и продолжительность времени разработки позволяет не потерять эту информацию из виду. Для больших проектов это, очевидно, не верно. Т.к. если по коду начала гулять не полностью заполненая BE, нет гарантии, что она не попадет в метод, который расчитывает, что некоторое поле в этой BE обязательно должно быть проинициалированным. Другими словами, выполнение правила "Все поля BE должны быть проинициализированы" гораздо легче контролировать, чем выполнения правила "Частично заполненные BE не должны попасть в код, который будет использовать непроинициалированные поля". Т.к. в первом случае, мы должны контролировать только точки создания BE, а во втором все дерево переходов BE по коду. Я могу согласиться с таким подходом лишь в случае проектирования внешнего API к системе, т.к. видел пример хорошего решения(eBay XML и SOAP API). Там в каждом запросе к API передается поле DetailLevel и для каждого запроса в документации определена таблица для каких значений DetailLevel, какие поля будут возвращены.

IT>После вот этого утверждения дискуссию можно было бы закончить.
Ну это утверждение было известно до начала дискуссии, т.к. в посте на который я привел ссылку было сказано

С другой стороны, пусть тебе нужны данные для грида где ты отображаешь информацию...

Впрочем, с остальным я согласен. Отмечу только, что поведение и цели подобных классов слишком сильно отличаются скажем, то тех же Order, Customer или Address. Отличие в следующем:
1. Эти контейнеры предназначены исключительно для передачи информации наружу из бизнес-логики. Т.е. они не принимают участие во внутренних процессах.
2. Вероятность изменения для них значительно выше, т.к. они в большей степени зависят от мимолетных пожеланий клиентов, чем от инертной предментной области.
...
Эти отличия должны быть явно зафиксированы в коде, например введением абстрактного класса или использованием атрибутов, т.к. такой подход значительно упрощает жизнь в дальнейшем. Кроме того, учитывая, что изменения обоих типов зависят от разных требований — они должны быть соотвественно разделены и физически.

IT>Давай попробуем разобраться без догм и фанатизма. Что такое контейнеры для данных, описывающие предметную область или что угодно другое? Это объектная модель, на которой строится функциональность приложения. Верно? Верно. У клиентского UI приложения может быть своя объектная модель, на которой строится фукнциональность UI приложения? Может. Тогда какая по сути принципиальная разница между объетной моделью UI приложения и BE, которые есть контейнеры данных, описывающие предметную область? Совершенно верно, ни-ка-кой. И то, и другое суть контейнеры, предназначение которых обеспечить совместно с логикой приложения работу системы в соответствии с функциональными требованиями.

Тоже согласен, с небольшими "но" описанными выше.

Здравствуйте, GlebZ, Вы писали:

GZ>Вот в данном случае не соглашусь. Основная цель DTO, как и всего презентационного слоя является изоляция логики сервера от логики клиента. DTO — является частью презентационного слоя. Эффективная пересылка — это уже другая цель.

Разве? А если обмен осуществляется не между презентационным слоем и сервером, а между одним сервером и другим? То что такое DTO в данном случае?

Не надо давать свою интерпретацию терминам. DTO — это data transfer object. Заметь — transfer, не DTPO — data transfer & presentation object. Только transfer.

Здравствуйте, IT, Вы писали:

IT>Не надо давать свою интерпретацию терминам. DTO — это data transfer object. Заметь — transfer, не DTPO — data transfer & presentation object. Только transfer.
Presentation — это слой. И DTO является частью его.

Здравствуйте, MaximVK, Вы писали:

IT>>Это всё твои домыслы и ничего более. Никто никаких методов без крайней необходимости писать не будет. Необходимость проверки полей мне не будет нужна по одной простой причине. Если я не включаю данные в объект, то логично предположить, что я не собираюсь их использовать. Неожиданный поворот, не правда ли

MVK>Отнюдь, вполне ожидаемый , т.к. именно эта аргументация приводиться чтобы оправдать такой подход. Неожиданность в другом — я не ожидал услышать такой, прямо скажем, слабой аргументации от тебя.

Ну тогда послушай, что тебе говорят. Все твои опасения напрасны. Минусы у такого подхода конечно есть, но они мизрны по сравнению с теми плюсами, которые он даёт.

MVK>Для небольшого проекта или прототипирования — это вполне разумный подход, который экономит время, а количество кода, сотрудников и продолжительность времени разработки позволяет не потерять эту информацию из виду. Для больших проектов это, очевидно, не верно.

Дать определение большого проекта не затруднит?

MVK>Т.к. если по коду начала гулять не полностью заполненая BE, нет гарантии, что она не попадет в метод, который расчитывает, что некоторое поле в этой BE обязательно должно быть проинициалированным. Другими словами, выполнение правила "Все поля BE должны быть проинициализированы" гораздо легче контролировать, чем выполнения правила "Частично заполненные BE не должны попасть в код, который будет использовать непроинициалированные поля". Т.к. в первом случае, мы должны контролировать только точки создания BE, а во втором все дерево переходов BE по коду.

Тогда вернёмся на несколько постов назад. По-твоему, если у тебя есть объект из 30 полей, но тебе нужно только 5, то ты создаш новый объект. Если же тебе понадобились 6 полей, то ещё один объект, если 6, но других, то по объекту на каждую комбинацию, если 7, то все возможные комбинации и так далее. Я тебя правильно понимаю?

MVK>Я могу согласиться с таким подходом лишь в случае проектирования внешнего API к системе, т.к. видел пример хорошего решения(eBay XML и SOAP API). Там в каждом запросе к API передается поле DetailLevel и для каждого запроса в документации определена таблица для каких значений DetailLevel, какие поля будут возвращены.

Так в чём проблема? Если речь идёт о большом проекте, то сопроводи свой метод спецификаций.

IT>>После вот этого утверждения дискуссию можно было бы закончить.
MVK> Ну это утверждение было известно до начала дискуссии, т.к. в посте на который я привел ссылку было сказано

С другой стороны, пусть тебе нужны данные для грида где ты отображаешь информацию...

Извини, не заметил.

MVK>Впрочем, с остальным я согласен. Отмечу только, что поведение и цели подобных классов слишком сильно отличаются скажем, то тех же Order, Customer или Address. Отличие в следующем:
MVK>1. Эти контейнеры предназначены исключительно для передачи информации наружу из бизнес-логики. Т.е. они не принимают участие во внутренних процессах.

Блин, ну вот опять начинается Как же они не принимают участие во внутренних процессах, если задача внутренных процессов как раз и заключается в том, чтобы создать структуру из таких объектов и вернуть её клиенту. Это и есть работа этих самых внутренных процессов.

MVK>2. Вероятность изменения для них значительно выше, т.к. они в большей степени зависят от мимолетных пожеланий клиентов, чем от инертной предментной области.

Эти изменения прежде всего неразрывно связаны с изменением логики работы сервера.

MVK>Эти отличия должны быть явно зафиксированы в коде, например введением абстрактного класса или использованием атрибутов, т.к. такой подход значительно упрощает жизнь в дальнейшем. Кроме того, учитывая, что изменения обоих типов зависят от разных требований — они должны быть соотвественно разделены и физически.

И почему же они тогда не разделены?

Hello, "GlebZ"
> Здравствуйте, IT, Вы писали:
>
> IT>Не надо давать свою интерпретацию терминам. DTO — это data
> transfer object. Заметь — transfer, не DTPO — data transfer &
> presentation object. Только transfer.
> Presentation — это слой. И DTO является частью его.

А можно, для тех кто в танке? т.е. DTO как часть presentation слоя
используются только в нем и выше? Или, data слой зависит от объектов
presentation слоя и все это дело крепко замешано друг на друга?

Здравствуйте, GlebZ, Вы писали:

IT>>Не надо давать свою интерпретацию терминам. DTO — это data transfer object. Заметь — transfer, не DTPO — data transfer & presentation object. Только transfer.
GZ>Presentation — это слой. И DTO является частью его.

А частью бизнес логики не является?

Здравствуйте, TK, Вы писали:

TK>А можно, для тех кто в танке? т.е. DTO как часть presentation слоя
TK>используются только в нем и выше? Или, data слой зависит от объектов
TK>presentation слоя и все это дело крепко замешано друг на друга?
Для тех кто в танках, самоходках и на доблестных кораблях краснознаменного балтийского флота. Слой — это добровольное обязательство разработчика для изоляции некоторой логики находящейся между другими слоями. Presentation layer, или иногда именуюмый фасадным слоем — это слой предназначенный для защиты независимости реализации бизнес-логики сервера от посягательтв клиентов. Сущности реализуемые в слое — по крайней мере не должны противоречить той цели ради которой построен слой. DTO — снимает проблему зависимости серверной бизнес-логики по данным.
Если мы не ставим себе задачу обеспечить независимость передаваемых данных от реализации бизнес-логики на сервере — хорошо. Баба с возу, кобыле легче. Заботу о формировании DTO обеспечивается стандартными средствами. Если мы должны это сделать по каким-то причинам — то это функция presentation layer.
Что касается смешения соседствующих слоев, а правильнее говорить о зависимости — то они безусловно зависят друг от друга, и это не есть противоречие.

Здравствуйте, IT, Вы писали:

GZ>>Presentation — это слой. И DTO является частью его.

IT>А частью бизнес логики не является?
Смотря что имеется ввиду под бизнес логикой. Если говорить о бизнес-логике как о реализации некоторой предметной логики — то нет. Это сервисная логика.

Здравствуйте, GlebZ, Вы писали:

GZ>>>Presentation — это слой. И DTO является частью его.

IT>>А частью бизнес логики не является?

GZ>Смотря что имеется ввиду под бизнес логикой. Если говорить о бизнес-логике как о реализации некоторой предметной логики — то нет. Это сервисная логика.

Я без понятия что такое предметная логика. Так же не знаком с термином сервисная логика. Поэтому, во избежании терминологической путаницы поясню, что для меня бизнес логика. Бизнес логика в моём понимании — это часть системы, которая занимается реализацией функциональных требований.

Ответь пожалуйста на вопрос, DTO являются частью этой логики? Если можно без изобретения новых терминов.

Здравствуйте, GlebZ, Вы писали:

GZ>Для тех кто в танках, самоходках и на доблестных кораблях краснознаменного балтийского флота. Слой — это добровольное обязательство разработчика для изоляции некоторой логики находящейся между другими слоями. Presentation layer, или иногда именуюмый фасадным слоем — это слой предназначенный для защиты независимости реализации бизнес-логики сервера от посягательтв клиентов.

О как! Presentation у нас уже стал синонимом контракта
Т.е. WPF, по-твоему, это не фреймворк для разработки UI, а нечно для создания фасадов серверов.
Я конечно всё понимаю, и вполне осознаю, что вся эта дискуссия всего лишь терминологический трёп. Но не до такой же степени

GZ>Сущности реализуемые в слое — по крайней мере не должны противоречить той цели ради которой построен слой. DTO — снимает проблему зависимости серверной бизнес-логики по данным.

Тут в соседней ветке MaximVK утверждает, что он использует DTO для того, чтобы поднять данные из базы, отправить их клиенту и там забаиндить их на грид. Т.е. его DTO участвуют в полном цикле запроса, от DAL до UI. Покажи мне здесь, пожалуйста, противоречивость и проблемы, которые снимают DTO.

GZ>Если мы не ставим себе задачу обеспечить независимость передаваемых данных от реализации бизнес-логики на сервере — хорошо. Баба с возу, кобыле легче. Заботу о формировании DTO обеспечивается стандартными средствами. Если мы должны это сделать по каким-то причинам — то это функция presentation layer.

Вообще-то, это называется контрактом. А как я уже говорил, число задач, где возникает реальная, а не высосанная из пальца необходимость в контрактах стремится к нулю.

Hello, "GlebZ"
> TK>Или, data слой зависит от объектов
> TK>presentation слоя и все это дело крепко замешано друг на друга?

> Для тех кто в танках, самоходках и на доблестных кораблях краснознаменного
> балтийского флота. Слой — это добровольное обязательство разработчика
> для изоляции некоторой логики находящейся между другими слоями.
> Presentation layer, или иногда именуюмый фасадным слоем — это слой
> предназначенный для защиты независимости реализации бизнес-логики сервера
> от посягательтв клиентов. Сущности реализуемые в слое — по крайней мере не
> должны противоречить той цели ради которой построен слой. DTO — снимает
> проблему зависимости серверной бизнес-логики по данным.

Круто загнул... Только что были гриды, биндинг на формочки а тут, бац... мы
уже на сервере Какой-то он слишком "жирный" этот presentaion layer при
таком подходе выходит. И данные на формочки маппит и со стороны сервера
доступ предоставляет... Не лучше бы его разделить? На сервере оставить фасад
предоставляющий сервисы, а на клиенте UI т.е. presentation. В любом случае,
не понятно как DTO снимает зависимость от серверной бизнес логики если части
клиентского presentation тоже крутятся на сервере...

> Что касается смешения соседствующих слоев, а правильнее говорить о
> зависимости — то они безусловно зависят друг от друга, и это не есть
> противоречие.

Слои должны смешиваться только в одном направлении. Если же смешение
происходит в обе стороны то, такой подход это однозначный кандидат на
очередной антипаттерн.

Здравствуйте, IT, Вы писали:

IT>Ответь пожалуйста на вопрос, DTO являются частью этой логики? Если можно без изобретения новых терминов.
Без изобретения есть функциональные требования, а есть нефункциональные требования. Генерация DTO — обеспечение нефункциональных требований.

Здравствуйте, GlebZ, Вы писали:

IT>>Ответь пожалуйста на вопрос, DTO являются частью этой логики? Если можно без изобретения новых терминов.
GZ>Без изобретения есть функциональные требования, а есть нефункциональные требования. Генерация DTO — обеспечение нефункциональных требований.

Я не задавал этот вопрос. Мой вопрос был являются ли DTO частью бизнес логики или нет.

Впрочем, твой ответ, если внимательно посмотреть, лишь подтверждает мои слова

Здравствуйте, IT, Вы писали:

IT>Тут в соседней ветке MaximVK утверждает, что он использует DTO для того, чтобы поднять данные из базы, отправить их клиенту и там забаиндить их на грид. Т.е. его DTO участвуют в полном цикле запроса, от DAL до UI. Покажи мне здесь, пожалуйста, противоречивость и проблемы, которые снимают DTO.
Сложность терминологии. У него нет как таковых BE. Он начал интерпретировать данные не как объект, а как данные.

IT>Вообще-то, это называется контрактом.
Правильно. А из чего состоит контракт в общем случае? Каким образом при версионификации серверов — можно публиковать и новый и старый контракты при более новой реализации?

IT>А как я уже говорил, число задач, где возникает реальная, а не высосанная из пальца необходимость в контрактах стремится к нулю.
Повторюсь. Зависит от специфики. Охотно верю что для тебя к нулю.

Здравствуйте, TK, Вы писали:

TK>Круто загнул... Только что были гриды, биндинг на формочки а тут, бац... мы
TK>уже на сервере Какой-то он слишком "жирный" этот presentaion layer при
TK>таком подходе выходит. И данные на формочки маппит и со стороны сервера
TK>доступ предоставляет... Не лучше бы его разделить? На сервере оставить фасад
TK>предоставляющий сервисы, а на клиенте UI т.е. presentation. В любом случае,
TK>не понятно как DTO снимает зависимость от серверной бизнес логики если части
TK>клиентского presentation тоже крутятся на сервере...
Есть у меня подозрение что у нас возникла сложность в терминологии. Под presentation layer не очень хороший термин, поскольку в разных технологиях обозначает разные вещи. Даю синонимы — service interface, remote facade, фасадные классы. UI — тут побоку.

TK>Слои должны смешиваться только в одном направлении. Если же смешение
TK>происходит в обе стороны то, такой подход это однозначный кандидат на
TK>очередной антипаттерн.
Нет. И к тому же это чаще просто невозможно сделать. Зависимости всегда остаются. Вызовы только с одной стороны можно сделать. Но изменение кода на одном слое могут выливаться изменения на соседних слоях.

Здравствуйте, IT, Вы писали:

IT>Я не задавал этот вопрос. Мой вопрос был являются ли DTO частью бизнес логики или нет.
Ты сам дал ответ.

Бизнес логика в моём понимании — это часть системы, которая занимается реализацией функциональных требований.

DTO — это обеспечение operation requirement.

IT>Впрочем, твой ответ, если внимательно посмотреть, лишь подтверждает мои слова
Какие?