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

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

GT>>Ну если вы предлагаете использовать одну и ту же сущность. И вот представление меняется, занчит и сущность надо поменять, чтобы отдавать чуть другие данные.
B>Жесть какая-то. Представление берет любую сущность и представляет её в нужном виде. Почему из задачи поменять представление незаменимо следует "поменять сущность", мне не понятно.

GT>>Но это означает и базу придется менять, тк. представление уже не соответсвует модели.
B>Блин, слои для того и придумали, чтобы изменение одного слоя ограничивало "плюх" эти слоем. Почему у вас при изменении представления нужно менять модель предметной области и базу, мне не понятно.

Еще раз, как я вас понял.. Что якобы слои не нужны, надо маппинг доступа к бд, бизнес логикиу, и представление слепить в одну сущность. Сейчас же вы говорите что слои нужны.. Извините если не правильно понял.

B>>>http://www.schemacentral.com/sc/niem21/ss.html
GT>>Честно, не понял что это такое.
B>Это модель предметой области.

GT>>Я к тому что если передавать всю иерархию сущностей как есть, то можно передать ненароком секретные данные.
B>Ненароком можно передать всё что хочешь. Если нужна секурность на уровне свойств, то почему бы её и не реализовать отдельным слоем, который даёт\запрещает достум к свойствам.
B>Я не вижу смысла хардкодить в модели то что динамически меняеться конфигурацией.
B>Даже если нужны секурные свойства. ОК.
B>FullPerson -> SecuredPersonInfo -> PublicPersonInfo -> BasicPersonInfo


GT>>Тоесть насколько я понял, вы предлагаете не меняя исходной структуры модели передавать каждый раз только те данные которые нужны представлению. А кто будет решать какие данные нужны а какие нет, для каждого конкретного запроса, и кто это будет разруливать?
B>Протокол обмена между представлением и бизнес логикой. Мне воот теперь вообще интересно посмотреть на вашу бизнес логику. Она у вас, скорее, выходит совершенно анемичной.
B>К примеру, у меня на View есть PersonWithName, в котором нет DOB, потому что он в SecuredPersonInfo.
B>В результате мне чтобы посчитать AGE нельзя просто взять Person.calcAge(), мне нужно дописать Age в PersonWithName, и в маппинге.
B>Я уже задал этот вопрос выше. Как вы переиспользуете логику бизнес-объектов в слоях, где у вас вместо бизнес-объектов лишь обрубки?

Отчего вы решили что вместо бизнес объектов у нас обрубки? "у меня на View есть PersonWithName" это вы про свой проект говорите, или иносказательно про мой?
Допустим про мой.. Итак есть бизнес объект PersonBO, и вьюшка PersonWithNameVO. Делаем в PersonBO метод вычисляющий возраст, и обзываем getAge(). Далее во вьюшке делаем свойство age. Все.
Маппер замапит возраст на вьюшку. Нужен будет этот ворзаст в какой нибудь PersonFullInfoVO — тоже делается свойство age, или наследуется от PersonWithNameVO, тут по ситуации.