DTO и взаимодействие с бизнес-сущностями - Архитектура программного обеспечения

Здравствуйте, Аноним, Вы писали:

А>Реализуется трёхзвенное приложение. На СП создаются объекты ДТО, в них копируются данные из Рекордсета и передаются клиенту. Правильный ли это подход? И ещё вопрос. Предположим что часть полей считаны из БД а часть должны быть вичислены. Вычисления делать в ДТО или на клиенте в бизнес-объекте?

Для ясности, я бы рекомендовал разделять DTO обьекты и бизнес обьекты (т.к. они относятся к разным слоям), иначе неприятности не заставят себя ждать.

Имхо лучший пример DTO — DataSet т.е. мапирование данных из таблиц DB 1:1 (позволит избежать путаницы при получении и обновлении данных). Кроме того DAC слой не имеет права знать о бизнес сущностях в которые DTO обьекты будут преобразованы. Т.е. DTO не ориентированы на предметную область, они ориентированы на табличное представление.

Бизнес обьекты получаются в результате преобразований обьектов DTO в слое бизнес логики.
И ориентированны на предметную область.

А>Для ясности, я бы рекомендовал разделять DTO обьекты и бизнес обьекты (т.к. они относятся к разным слоям), иначе неприятности не заставят себя ждать.

Так и есть. DTO создаются на СП и передаются в клиентское приложение, где находятся бизнес объекты.

А>Имхо лучший пример DTO — DataSet т.е. мапирование данных из таблиц DB 1:1 (позволит избежать путаницы при получении и обновлении данных). Кроме того DAC слой не имеет права знать о бизнес сущностях в которые DTO обьекты будут преобразованы.
Так и есть

А>Бизнес обьекты получаются в результате преобразований обьектов DTO в слое бизнес логики.
А>И ориентированны на предметную область.

Это у меня выполняется на клиенсткой стороне. Но вот какая ситуация. В ДТО есть информация, которая позволяет расчитать какие то недостоющие поля. Имеет смысл их расчитать сразу или сначало передать на клиента, скопировать в бизнес объекты и замет уж расчитать?

Здравствуйте, Аноним, Вы писали:

А>>Бизнес обьекты получаются в результате преобразований обьектов DTO в слое бизнес логики.
А>>И ориентированны на предметную область.

А>Это у меня выполняется на клиенсткой стороне. Но вот какая ситуация. В ДТО есть информация, которая позволяет расчитать какие то недостоющие поля. Имеет смысл их расчитать сразу или сначало передать на клиента, скопировать в бизнес объекты и замет уж расчитать?

Имхо зависит от обьема доп. данных, вероятности изменения алгоритма расчета или еще чего-то. Если доп. данные не востребованы за рамками ДТО вроде как ответ очевиден — нечего им делать в бизнес обьектах.

А>Имхо зависит от обьема доп. данных, вероятности изменения алгоритма расчета или еще чего-то. Если доп. данные не востребованы за рамками ДТО вроде как ответ очевиден — нечего им делать в бизнес обьектах.

Так ДТО не общий для всех бизнес сущностей. Они соответствуют бизнес-сущностям. Поэтому при изменении бизнес-процессов, скорее всего будет меняться и ДТО....

Интересно с чем был не согласен человек который поставил -1?

Едиственное с чем я бы поспорил, так это с тем что:
А>>Имхо лучший пример DTO — DataSet

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

и вот с этим:
А>>Кроме того DAC слой не имеет права знать о бизнес сущностях в которые DTO обьекты будут преобразованы.

В ряде случаев, когда бизнес-объекты достаточно просты по структуре можно отказаться DTO для них и оперировать непосредственно бизнес-объектами, в том числе и в DAL-слое. DTO в ощем случае опционален. Ну и естественно он не предназначен для использования в качестве контейнера какой-либо бизнес логики.

p/s/
В целом же ответ был позитивным и отчасти полезным, и не понимаю почему чел поставил -1, при этом не оставив никаких комментариев. Считаю такие оценки простым невежеством...

Здравствуйте, Аноним, Вы писали:

А>>Имхо зависит от обьема доп. данных, вероятности изменения алгоритма расчета или еще чего-то. Если доп. данные не востребованы за рамками ДТО вроде как ответ очевиден — нечего им делать в бизнес обьектах.

А>Так ДТО не общий для всех бизнес сущностей. Они соответствуют бизнес-сущностям. Поэтому при изменении бизнес-процессов, скорее всего будет меняться и ДТО....

Имхо совершенно неверно, ДТО вообще не должны зависеть от бизнес сущностей, они зависят только от структуры БД. От бизнес сущностей зависят бизнес обьекты (отвечающие за доменно-ориентированное представление данных).

Здравствуйте, снежок, Вы писали:

С>Интересно с чем был не согласен человек который поставил -1?

Он наверно не согласен "в принципе".

С>Едиственное с чем я бы поспорил, так это с тем что:
А>>>Имхо лучший пример DTO — DataSet

Лучший пример как лучшее пояснение, а ни в коем случае не реализация. Хотя ручная реализация ДТО имхо для новичков самая верная техника для того, чтобы испортить представление о ДТО обьектах. У новичков ДТО быстренько сливаются в кучу с бизнес обьектами (а особенно если разработчика подгоняют) и в результате получает ацкий "спагетти-код" из двух слепленных вместе слоев DAC + BL.

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

С>и вот с этим:
А>>>Кроме того DAC слой не имеет права знать о бизнес сущностях в которые DTO обьекты будут преобразованы.

С>В ряде случаев, когда бизнес-объекты достаточно просты по структуре можно отказаться DTO для них и оперировать непосредственно бизнес-объектами, в том числе и в DAL-слое. DTO в ощем случае опционален. Ну и естественно он не предназначен для использования в качестве контейнера какой-либо бизнес логики.

Согласен с подходом, не согласен с формулировкой, ДТО никогда не должны рассматриваться как бизнес обьекты. Хотя иногда бизнес обьекты могут быть получены преобразованием 1:1 из ДТО обьектов, и тут БО конечно бессмысленны (до того момента как преобразование 1:1 изменится). Ну и есть еще особенная область — отчеты, где часто БО обьекты тоже не нужны.

Здравствуйте, Аноним, Вы писали:

А>>Так ДТО не общий для всех бизнес сущностей. Они соответствуют бизнес-сущностям. Поэтому при изменении бизнес-процессов, скорее всего будет меняться и ДТО....

А>Имхо совершенно неверно, ДТО вообще не должны зависеть от бизнес сущностей, они зависят только от структуры БД. От бизнес сущностей зависят бизнес обьекты (отвечающие за доменно-ориентированное представление данных).

DTO не зависит ни от BO, ни от структуры БД. Пержде всего это только объект переноса данных. И каких данных — это дело каждого спроектированного вызова. Как DTO мапиться на таблицы БД, а может, кстати, он мапиться не на таблицы, а на параметры хп, а — это дело маппера. Так что в общем случае DTO еще, поюс ко всему, выступает и в роли посредника обеспечивающего слабое связывание м/у BO-layer и DAL.

p.s.
То что DTO "зависят" от BO — я не увидел этого слова.
"Соответствуют" — могут соответствовать! А могут и не соответствовать! Ничего предосудительного в обоих вариантах нет и выбираются в зависимости от ситуации.

Здравствуйте, <Аноним>, Вы писали:

А>Для ясности, я бы рекомендовал разделять DTO обьекты и бизнес обьекты (т.к. они относятся к разным слоям), иначе неприятности не заставят себя ждать.

А я для простоты порекомендовал бы не приумножать сущности сверх необходимости и следовать существующим, хорошо себя зарекомендовавшим архитектурам, например, от MS. А в ней деление на BizEntity и DTO нет.