Здравствуйте, GreenTea, Вы писали:
GT>Ну если вы предлагаете использовать одну и ту же сущность. И вот представление меняется, занчит и сущность надо поменять, чтобы отдавать чуть другие данные.
Жесть какая-то. Представление берет любую сущность и представляет её в нужном виде. Почему из задачи поменять представление незаменимо следует "поменять сущность", мне не понятно.
GT>Но это означает и базу придется менять, тк. представление уже не соответсвует модели.
Блин, слои для того и придумали, чтобы изменение одного слоя ограничивало "плюх" эти слоем. Почему у вас при изменении представления нужно менять модель предметной области и базу, мне не понятно.
B>>http://www.schemacentral.com/sc/niem21/ss.html
GT>Честно, не понял что это такое.
Это модель предметой области.
GT>Я к тому что если передавать всю иерархию сущностей как есть, то можно передать ненароком секретные данные.
Ненароком можно передать всё что хочешь. Если нужна секурность на уровне свойств, то почему бы её и не реализовать отдельным слоем, который даёт\запрещает достум к свойствам.
Я не вижу смысла хардкодить в модели то что динамически меняеться конфигурацией.
Даже если нужны секурные свойства. ОК.
FullPerson -> SecuredPersonInfo -> PublicPersonInfo -> BasicPersonInfo
GT>Тоесть насколько я понял, вы предлагаете не меняя исходной структуры модели передавать каждый раз только те данные которые нужны представлению. А кто будет решать какие данные нужны а какие нет, для каждого конкретного запроса, и кто это будет разруливать?
Протокол обмена между представлением и бизнес логикой. Мне воот теперь вообще интересно посмотреть на вашу бизнес логику. Она у вас, скорее, выходит совершенно анемичной.
К примеру, у меня на View есть PersonWithName, в котором нет DOB, потому что он в SecuredPersonInfo.
В результате мне чтобы посчитать AGE нельзя просто взять Person.calcAge(), мне нужно дописать Age в PersonWithName, и в маппинге.
Я уже задал этот вопрос выше. Как вы переиспользуете логику бизнес-объектов в слоях, где у вас вместо бизнес-объектов лишь обрубки?
