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

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

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

Для ясности, я бы рекомендовал разделять 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 нет.

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

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


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

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

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

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

Согласен

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

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

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

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

Имхо порочная практика, особенно для новичков.

А чем отличаются BO-layer и DAL. DAL это уровень, реализованный на сервере СУБД? т.е. запросы и ХП? А BO-layer это мои бизнес-объекты?
.

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

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

А>Имхо порочная практика, особенно для новичков.

Что именно? Следование проверенным устоявшимся архитектурам?

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

А>Имхо порочная практика, особенно для новичков.

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

А применительно к исходному вопросу, нужно возвращать бизнес-сущности сразу с СП?

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

А>А чем отличаются BO-layer и DAL. DAL это уровень, реализованный на сервере СУБД? т.е. запросы и ХП? А BO-layer это мои бизнес-объекты?

DAL — это уровень, который отвечает за обращение к БД или к-либо другому хранилищу и производит отражение DTO/BO на хп и запросы идущие к хранилищу.

Здравствуйте, <Аноним>, Вы писали:
А> Ну и есть еще особенная область — отчеты, где часто БО обьекты тоже не нужны.
Это как посмотреть...
Никогда не встречалось понятие Report Data Object?

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

А>А применительно к исходному вопросу, нужно возвращать бизнес-сущности сразу с СП?

А что в данном контексте значит сразу?

P.S. Для "сервера приложений" лучше использовать "апп-сервер", а то первая мысль, возникающая когда наталкиваешься на СП — это то что речь идет о хранимых процедурах (stored procedure).

С>DAL — это уровень, который отвечает за обращение к БД или к-либо другому хранилищу и производит отражение DTO/BO на хп и запросы идущие к хранилищу.

То есть DataMappers? Они выполняют скл и результат из рекордсета перегоняют в объекты?

L>P.S. Для "сервера приложений" лучше использовать "апп-сервер", а то первая мысль, возникающая когда наталкиваешься на СП — это то что речь идет о хранимых процедурах (stored procedure).
Я это и емелл виду. СП реализован как Ремоутинг сервер

L>А что в данном контексте значит сразу?
Ну СП (АппСервер) посылает запрос к БД. А потом результат из Рекордсета копирует в объекты бизнес-сущностей. ТАк нужно? Без ДТО?

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

L>>P.S. Для "сервера приложений" лучше использовать "апп-сервер", а то первая мысль, возникающая когда наталкиваешься на СП — это то что речь идет о хранимых процедурах (stored procedure).
А>Я это и емелл виду. СП реализован как Ремоутинг сервер

Ambibuity detected.

L>>А что в данном контексте значит сразу?
А>Ну СП (АппСервер) посылает запрос к БД. А потом результат из Рекордсета копирует в объекты бизнес-сущностей. ТАк нужно? Без ДТО?

Это зависит от того, как ты работаешь бизнес-сущностями. Я предпочитаю не делать различий между BizObject-ами и DTO, а всю бизнес-логику выносить в бизнес-компоненты.

Здравствуйте, <Аноним>, Вы писали:
А>То есть DataMappers? Они выполняют скл и результат из рекордсета перегоняют в объекты?
Примерно так, но DataMapper стоит особняком и вообще может не пресутствовать, а все отражение может тупо реализоваться в CRUD-методах DAL.
DataMapper лишь может помочь сократить объем рутинного кода в CRUD-методах, но чаще приводит к потере гибкости и ясности.
Хороший ORM-маппер скорее исключение чем правило, к сожалению...

С>Примерно так, но DataMapper стоит особняком и вообще может не пресутствовать, а все отражение может тупо реализоваться в CRUD-методах DAL.
Так что такое DAL7 Это набор методов в бизнес-сущностях? Или это это отдельные классы?

С>DataMapper лишь может помочь сократить объем рутинного кода в CRUD-методах, но чаще приводит к потере гибкости и ясности.

За счёт чего теряется гибкость? Можно же иерархию ДатаМаперов сделать....

L>>>P.S. Для "сервера приложений" лучше использовать "апп-сервер", а то первая мысль, возникающая когда наталкиваешься на СП — это то что речь идет о хранимых процедурах (stored procedure).
А>>Я это и емелл виду. СП реализован как Ремоутинг сервер

L>Ambibuity detected.

Это что означает?

L>Я предпочитаю не делать различий между BizObject-ами и DTO, а всю бизнес-логику выносить в бизнес-компоненты.

А с точки зрения реализазии если рассмотреть. Получается что на АппСервере нужны ссылки на бизнес объекты предметной области. Так?

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


L>>Ambibuity detected.

А>Это что означает?

Забей.

L>>Я предпочитаю не делать различий между BizObject-ами и DTO, а всю бизнес-логику выносить в бизнес-компоненты.

А>А с точки зрения реализазии если рассмотреть. Получается что на АппСервере нужны ссылки на бизнес объекты предметной области. Так?

Конечно. Сервер приложений нужен чтобы вынести бизнес-логику с клиента, поэтому естественно он оперирует бизнес-сущностями.

А>>А с точки зрения реализазии если рассмотреть. Получается что на АппСервере нужны ссылки на бизнес объекты предметной области. Так?

L>Конечно. Сервер приложений нужен чтобы вынести бизнес-логику с клиента, поэтому естественно он оперирует бизнес-сущностями.

А если такая ситуация. Есть несколько приложений с различными бизнес-сущностями. Получается что СП должен иметь ссылки на все?

Здравствуйте, <Аноним>, Вы писали:
А>Так что такое DAL7 Это набор методов в бизнес-сущностях? Или это это отдельные классы?
По-правильному — отдельные классы.
Но некоторые ORM сливают BO и DAL воедино и тогда получается что это набор методов в бизнес-сущностях, что в общем случае неправильно.

С>>DataMapper лишь может помочь сократить объем рутинного кода в CRUD-методах, но чаще приводит к потере гибкости и ясности.
А>За счёт чего теряется гибкость? Можно же иерархию ДатаМаперов сделать....
Разные способы есть — и на иерархиях, и на метаинформации класса, атрибутах...
Проблемы именно с гибким маппингом? отражать ли параметры из сигнатуры метода и какие?
Какие свойства объекта отражать?
На какую хп или на какой текст запроса отражать?
Чаще это решается путем создания различных xml-схем отражения или определением метаинформации в атрибутах классов.
И часто эти схемы отражения не так прозрачно выглядят как хотелось бы, и соответственно народу бывает лень в них разбираться, разрабатывать и прочее...
DataMapper-ы, как ни странно, чаще реализуют как один класс — маппинг-хелпер, использующий схемы отражения, а не как иерархию классов для каждого тип BO.

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

L>>Конечно. Сервер приложений нужен чтобы вынести бизнес-логику с клиента, поэтому естественно он оперирует бизнес-сущностями.

А>А если такая ситуация. Есть несколько приложений с различными бизнес-сущностями. Получается что СП должен иметь ссылки на все?

Конечно, если код работает с сущностями, то ему нужны соответствующие сборки. Почему тебя это удивляет?

L>Конечно, если код работает с сущностями, то ему нужны соответствующие сборки. Почему тебя это удивляет?

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

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

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

А>>Имхо порочная практика, особенно для новичков.

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

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

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

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

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

А>>Имхо порочная практика, особенно для новичков.

L>Что именно? Следование проверенным устоявшимся архитектурам?
Ага, если эти проверенные устоявшиеся архитектуры каждый понимает по своему.

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

А>А если такая ситуация. Есть несколько приложений с различными бизнес-сущностями. Получается что СП должен иметь ссылки на все?

Да конечно не обязательно, ингда такой подход ведет к большим неприятностям. Проверка простая — если нек. сущность клиентом не используется, нечего ей там делать. Иначе растет связанность.

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

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

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

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

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