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

GT>Еще раз, как я вас понял.. Что якобы слои не нужны, надо маппинг доступа к бд, бизнес логикиу, и представление слепить в одну сущность. Сейчас же вы говорите что слои нужны.. Извините если не правильно понял.
Слои нужны. Не нужны копии слоёв. У вас 3 копии одного и того же слоя. И инструмент копирования между ними. А всё почему? Потому что бизнес модель какого-то невероятным образом отличается от модели БД и их нельзя замапить средствами работы с БД и приходится вводить новый слой. Аналогично и UI с какого-то перепугу не ложится на бизнес модель вообще и не может использовать всё её "гибкость".


GT>Отчего вы решили что вместо бизнес объектов у нас обрубки? "у меня на View есть PersonWithName" это вы про свой проект говорите, или иносказательно про мой?
Про ваш. У вас же "секурные" данные, которые нельзя отдавать на View слой. И если View слою нужно вычислить бизнес метод? У меня например, в бизнес-сущностях куча вычислимых свойств. Эти свойства вычисляются из нескольких связаных сущностей и их свойст. Эти свойства используются на всех уровнях, и на View и на бизнес-транзакциях и в ORM интерцепторах и на межсерверной синхронизации.
Вы же предлагаете под каждое такое вычислимое свойство заводить новое? Зачем? Это же как-то надо изолировать и контролировать чтобы оно было актуальным.

GT>Допустим про мой.. Итак есть бизнес объект PersonBO, и вьюшка PersonWithNameVO. Делаем в PersonBO метод вычисляющий возраст, и обзываем getAge(). Далее во вьюшке делаем свойство age. Все.
Куча лишних телодвижений. В то время как я добавляю вычислимое свойство getAge(), вам нужно добавить его в остальные слои как сосояние и проверить что маппинг копирует значение.

GT>Маппер замапит возраст на вьюшку. Нужен будет этот ворзаст в какой нибудь PersonFullInfoVO — тоже делается свойство age, или наследуется от PersonWithNameVO, тут по ситуации.
Понятно. По бритве Оккама моё решение лучше, потому что проще.