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

А>>Есть маленький вопрос по этому примеру. Если предположим надо вернуть часть данных
А>>из БО document, то где должна сидеть логика, что дать, а что нет. В DTOAssembler ?
GZ>Тут вопрос в том, зачем это нужно. Если это логика безопасности, то это отдельный механизм, который обычно реализуется как на уровне базы (вьюхи, хранимки, импесонализация (хотя и не очень приятный процесс), или просто добавление условий на select), так и на уровне бизнес логики (проверка могу ли я сохранить данный тип объекта). Однако я не советую делать безопасность на поля. Лучше разделить объекты.
GZ>Второй вопрос, если это нужно чтобы уменьшить оверхед трафика. В данном случае советую просто делать при переносе бизнес-объекта в формат DTO.

GZ>Делать полузаполненный бизнес-объект (и вообще трогать права суперпользователя) не стоит. Никогда не разберешься что этот объект содержит, и какие из полей понадобятся. Что касается суперпользователя, то во многих случаях нужно иметь информацию об объектах, на которые прав у текущего пользователя нет. Особенно в агрегирующих отчетах.

GZ>С уважением, Gleb.

Дело не безопасности, а желании клиента.
Каждый клиент заинтересован в какой-то определенной информации.
Вот и получается, что одному надо все поля БО, а кому-то всего 2 поля.
Сейчас у меня есть следующая ситуация : есть БО Company, которая агрегирует CompanyFinancialDetailes. Мой меппер возвращает заполненный БО Company и CompanyFinancialDetailes(отношения у них 1-1). Есть юзер который хочет пару полей из БО Company и адреса. Адреса хранятся в отдельной таблице, значит надо составлять новый запрос под клиента с адресами. Т.е вариаций много, но как всё построить, что-бы не было неразберихи, какая функция меппара что подгружает.