С>>+ Не требуется (или минимальный) маппинг 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)?

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

Спасибо.