Суть в том чтобы все get-ы и set-ы BO работали с DTO, а не приватными мемберами соответствующих свойств BO.
DTO представяет собой простую структуру (OrderDTO).
Плюсы очевидны:
+ BO не загромождены приватными членами свойств, код зрительно более приятный.
+ Не требуется (или минимальный) маппинг BO->DTO для передачи DTO сервисам и DataAccessLayer-у, так же отпадает необходимость реализации всяких criteria-паттернов (like criteria in CSLA.NET).

Вопрос:
А какие минусы или подводные камни у такого подхода?
Могут ли здесь возникнуть сложности при использовании mapper-helper-ов, того же BusinessToolKit-а?

    public struct OrderDTO
    {
        public int OrderID;
        public System.DateTime OrderDate;
    }


public class Order
    {
        private OrderDTO data;
        

    public System.DateTime OrderDate 
        {
            get 
            {
                return data.OrderDate;
            }
            set 
            {
                data.OrderDate = value;
            }
        }
}

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

С>Плюсы очевидны:
С>+ BO не загромождены приватными членами свойств, код зрительно более приятный.
Не очень серъезный плюс. Код достаточно нагляден.
С>+ Не требуется (или минимальный) маппинг BO->DTO для передачи DTO сервисам и DataAccessLayer-у, так же отпадает необходимость реализации всяких criteria-паттернов (like criteria in CSLA.NET).
Обычно объекты хранятся в коллекциях. Какой тип будет у коллекций для DTO и для DAL?

С>>+ Не требуется (или минимальный) маппинг BO->DTO для передачи DTO сервисам и DataAccessLayer-у, так же отпадает необходимость реализации всяких criteria-паттернов (like criteria in CSLA.NET).
GZ>Обычно объекты хранятся в коллекциях. Какой тип будет у коллекций для DTO и для DAL?
Да, с передачей коллекций особый разговор.
Для данной схемы я исхожу из следующих требований/предположений:
-DAL работает только с DTO и понятия не имеет о BO.
-Сервисы отдают и получают также DTO, хотя в своем кеше хранят BO. При передачи/приеме сервисом DTO-объектов, DTO полученный/ отправляемый проходит через Security-фильтр. Происходит двусторонний маппинг (в соответствии с привелегиями) DTO клиента на DTO хранящемся в BO кеша сервиса. BO.DTO на стороне сервиса хранит полные данные. DTO предаваемый клиенту хранит только данные которые доступну клиенту в соответствии с его привелегиями.
Таким образом, достигается не только row-level и operation-level security, но и property-level security без необходимости инстацирования объектов на сервере по ссылке (MarchalByRef) или без необходимости Lazy-load.
-Что с коллекциями? — Как мне пока видится, это задача BO. BO хранит коллекцию DTO-объектов.

Как в данном случае передавать сервису иерархический объект?
-делать ли вызовы сервиса для каждого элемента коллекции, взяв его DTO для передачи (что извращает саму идею DTO как минимизация вызовов и трафика клиент<->сервис)?
-или сформировать массив DTO и предавать его как параметр [insertOrder(OrderDTO orderDTO, OrderItem[] orderItems)] (но тогда как быть с довольно разветвленными объектами, которых не мало)?
-или создавать отдельный класс для разветвленных DTO-объектов (но тогда ценность приведенного подхода "DTO внутри BO" оказывается сомнительной, поскольку опять приходим к маппингу BO->DTO)?

Все это те вопросы на которые я пока не нахожу для себя ответа, хотя сама идея, в общих чертах, мне нравится...

Спасибо.

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

С>Суть в том чтобы все get-ы и set-ы BO работали с DTO, а не приватными мемберами соответствующих свойств BO.

Я вот никогда не понимал, в чём вообще смысл разделения на DTO и BO? Потому что Фаулер так сказал?

Здравствуйте, IT, Вы писали:
IT>Я вот никогда не понимал, в чём вообще смысл разделения на DTO и BO? Потому что Фаулер так сказал?
Сокращение трафика, взаимодействие со сторонними сервисами, которые принимают данные по другой схеме чем та на которую завязывается собственная сериализация, чтобы ослабить связь между BO и DAL (иначе BO требует сборку DAL, а DAL требует сборку BO и кроме как динамической загрузкой сборок и фабрикой с синглетонами, или еще какими то хитрыми методами по типу динамических сборок, эту ситуацию не разрешить).

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

С>Здравствуйте, IT, Вы писали:
IT>>Я вот никогда не понимал, в чём вообще смысл разделения на DTO и BO? Потому что Фаулер так сказал?
С>Сокращение трафика,

За счёт чего?

С>взаимодействие со сторонними сервисами, которые принимают данные по другой схеме чем та на которую завязывается собственная сериализация,

Для сторонних сервисов обычно пишутся агенты, которые работают по схеме DAL, только не для БД, а для стороннего сервиса.

С>чтобы ослабить связь между BO и DAL (иначе BO требует сборку DAL,

А это ещё с какой радости?

С>а DAL требует сборку BO и кроме как динамической загрузкой сборок и фабрикой с синглетонами, или еще какими то хитрыми методами по типу динамических сборок, эту ситуацию не разрешить).

Да уж. Видимо у нас разное понимание что такое BO и какие у него функции. Ну да ладно.

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

С>>Сокращение трафика,
IT>За счёт чего?
За счет того что не передаются ненужные данные. Например, если один BO ссылается на другой, то для такой ссылки передается идентификатор, а не весь граф объекта с прочей шелухой (наименования...). Я конечно понимаю что могут существовать различные схемы, например, собственная сериализация, но все это не так прозрачно...
С>>взаимодействие со сторонними сервисами, которые принимают данные по другой схеме чем та на которую завязывается собственная сериализация,
IT>Для сторонних сервисов обычно пишутся агенты, которые работают по схеме DAL, только не для БД, а для стороннего сервиса.
С>>чтобы ослабить связь между BO и DAL (иначе BO требует сборку DAL,
IT>А это ещё с какой радости?
Например, возьмем lazy load.
Если BO работает всегда только через сервисы, независимо от контектса приложения, обращается ли этот BO за данными находясь на клиенте или внутри сервиса, тогда вопрос "А это ещё с какой радости" правомерен.
Но если вы хотите максимально оптимизировать производительность и сократить цепочку вызовов, то находясь на клиенте BO обращается к сервисам, а находясь внутри сервиса BO обращается к DAL (не зачем сервису в данном случае обращаться самому к себе, происходит локальный вызов).
Определить контекст приложения и направить вызов сервису или DAL — дело сервисных агентов или в данном случае более уместно понятие ProxyAgent.
С>>а DAL требует сборку BO и кроме как динамической загрузкой сборок и фабрикой с синглетонами, или еще какими то хитрыми методами по типу динамических сборок, эту ситуацию не разрешить).
IT>Да уж. Видимо у нас разное понимание что такое BO и какие у него функции. Ну да ладно.
Мое понимание BO основывается на книге: Rockford Lhotka. C# Business Object

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

IT>>Да уж. Видимо у нас разное понимание что такое BO и какие у него функции. Ну да ладно.
С>Мое понимание BO основывается на книге: Rockford Lhotka. C# Business Object

Мне, например, Lhotka не понравился...
Можешь посмотреть еще книги Eric Evans и Jimmi Nielsen (нажеюсь имена правильно пишу)по Domain-Driven Design. Просто в них описан не один подход (архиетктура), как в "C# Business Object", а несколько...

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

IT>Я вот никогда не понимал, в чём вообще смысл разделения на DTO и BO? Потому что Фаулер так сказал?

Кстати, кто-то пробовал передавать по WCF дата контракты (DTO) содержащие классы наследованые от EditableObject?
Все хочется попробовать, да руки не дойдут...

Здравствуйте, varely, Вы писали:
V>Просто в них описан не один подход (архиетктура), как в "C# Business Object", а несколько...
Подходов то, по пальцам пересчитать одной руки хватит...

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

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

С>>Суть в том чтобы все get-ы и set-ы BO работали с DTO, а не приватными мемберами соответствующих свойств BO.

IT>Я вот никогда не понимал, в чём вообще смысл разделения на DTO и BO? Потому что Фаулер так сказал?


например сложности с сериализацией BO

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

IT>>Я вот никогда не понимал, в чём вообще смысл разделения на DTO и BO? Потому что Фаулер так сказал?

EM>например сложности с сериализацией BO

Например?

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

С>Суть в том чтобы все get-ы и set-ы BO работали с DTO, а не приватными мемберами соответствующих свойств BO.
С>DTO представяет собой простую структуру (OrderDTO).
С>Плюсы очевидны:
С>+ BO не загромождены приватными членами свойств, код зрительно более приятный.
С>+ Не требуется (или минимальный) маппинг BO->DTO для передачи DTO сервисам и DataAccessLayer-у, так же отпадает необходимость реализации всяких criteria-паттернов (like criteria in CSLA.NET).

С>Вопрос:
С>А какие минусы или подводные камни у такого подхода?
С>Могут ли здесь возникнуть сложности при использовании mapper-helper-ов, того же BusinessToolKit-а?

Ни разу ещё не сталкивался с необходимостью выделять DTO в отдельную сущность. Данные находятся в том же классе где и свойства и нет никакого смысла их разделять.

В Java большинство (если не все) тулкиты справляются с частичной сериализацией. То есть если используется маппинг, то сериализуется только то что намаплено. Если используется сериализатор, то у него всегда есть средства указать какие поля или свойства не надо сериализовать.

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

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

B>Ни разу ещё не сталкивался с необходимостью выделять DTO в отдельную сущность.

Я тоже пока ни разу Но есть другие джависты, которые пишут книжки и пропагандируют в них свою точку зрения. А потом эти книжки читают дотнетчики и начинают задавать вот такие вопросы.

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

IT>Я тоже пока ни разу Но есть другие джависты, которые пишут книжки и пропагандируют в них свою точку зрения. А потом эти книжки читают дотнетчики и начинают задавать вот такие вопросы.

А можно поконкретнее кто именно? По-моему DTO ушли в небитие вместе с EJB2

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

IT>>Я тоже пока ни разу Но есть другие джависты, которые пишут книжки и пропагандируют в них свою точку зрения. А потом эти книжки читают дотнетчики и начинают задавать вот такие вопросы.

B>А можно поконкретнее кто именно? По-моему DTO ушли в небитие вместе с EJB2

Как кто? Дядька Фаулер Ваших кровей, джавист

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

IT>>>Я тоже пока ни разу Но есть другие джависты, которые пишут книжки и пропагандируют в них свою точку зрения. А потом эти книжки читают дотнетчики и начинают задавать вот такие вопросы.

B>>А можно поконкретнее кто именно? По-моему DTO ушли в небитие вместе с EJB2

IT>Как кто? Дядька Фаулер Ваших кровей, джавист

Да Фаулер. Да джавист. Да пишет про DTO. Но нет не могу согласится с тем что он особо его пропагандирует. Да есть такой паттерн. Да его можно использовать так-то.
"Patterns of Enterprise Application Architecture" опирается во многом на EJB2. Поэтому там про DTO подробно разжевано. Но мир-то изменяется. Уже появился материал вроде этого, который во многом пытается вскрыть недостатки DTO.

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

B>Да Фаулер. Да джавист. Да пишет про DTO. Но нет не могу согласится с тем что он особо его пропагандирует. Да есть такой паттерн. Да его можно использовать так-то.
B>"Patterns of Enterprise Application Architecture" опирается во многом на EJB2. Поэтому там про DTO подробно разжевано. Но мир-то изменяется. Уже появился материал вроде этого, который во многом пытается вскрыть недостатки DTO.

Меня не надо уговаривать. Я не понимал пользы от DTO ни до Фаулера, ни после

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

IT>Меня не надо уговаривать.
Никто не уговаривает тебя его пользовать. Но отрицать факты что есть паттерн DTO и что у него есть своя ниша не имеет смысла.

IT>Я не понимал пользы от DTO ни до Фаулера, ни после
Счастливчик, ты не имел дело с говноспецификациями вроде EJB? По-моему существует ряд ситуаций, где вполне можно применить DTO. Но я сейчас не хочу высасывать примеры из пальца, так как реально с такой надобностью не сталкивался.

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

IT>>Меня не надо уговаривать.
B>Никто не уговаривает тебя его пользовать. Но отрицать факты что есть паттерн DTO и что у него есть своя ниша не имеет смысла.

Я где-то утверждал обратное?

IT>>Я не понимал пользы от DTO ни до Фаулера, ни после
B>Счастливчик, ты не имел дело с говноспецификациями вроде EJB? По-моему существует ряд ситуаций, где вполне можно применить DTO. Но я сейчас не хочу высасывать примеры из пальца, так как реально с такой надобностью не сталкивался.

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