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

B>- монструозными вычислениями в Service с нарушением инкапсуляции (внутри классов та же логика выглядит, читается и поддерживается проще)
B>- необходимостью таскать за собой Service везде где вообще нужна логика — интерцеторы, GUI и пр.
Мне интересно как это вообще можно поддерживать. Ведь мне зачастую чтоб дернуть какой метод, нужно сделать это в контексте транзакции. А то и чтоб AOP обертка какая дергалась. Что, в Entity спрингом инжектить сервис чтоль? Я видел такое когда то в одном проекте — ужас! А логика то весьма может навороченная быть. И если метод вычисления возраста еще имеет смысл в сам класс Entity добавить, то метод рассчета каких нидь процентов по кредиту — это по любому внешний сервис, если ты не враг себе. Ибо для рассчета этих процентов возможно потребуется сделать запрос через 10 различных вебсервисов, чтоб это не тормозило, еще и кучу кеширования делать — это явно не в Entity пихать нужно. И сервис слой по любому будет.

B>Service это паттерн TransactionScript. Там живут бизнес транзакции. Вынос вообще всей логики из бизнес-объектов в Service приводит к трудно четаемому и слабо переиспользоваемому коду. И ещё к процедурному стилю.
Процедурный стиль это что то плохое? Лично я стили всегда мешаю, и пишу как в ООП, так и в функциональном и процедурном. А иногда и декларативном. Серебрянной пули нет. И во многих случаях как раз применение процедурного стиля — это как раз улучшение читаемости и повторной используемости.

E>>Кроме того, пограничные слои, которые оперируют с DTO — им 100 лет не сдались эти бизнес методы. Пограничные слои в основном визуализацией занимаются этой уже подготовленной DTO. Если нужны бизнес методы — будет вызов идти к сервису бизнес логики, а он как раз будет оперировать не с DTO, а с самой что ни на есть Entity, и все методы будут доступны.
B>Это не так. Я уже приводил примеры выше. ORM Interceptor оперирует одними бинами, а бизнес логика в других (как предлагает автор статьи). Service туда тянуть? Чтобы посчитать, например, возраст? Так сервис же у нас оперирует BO бинами. Что делать?
Я не очень понимаю необъодимость отдельных бинов для бизнес логики, отличных от ORM. Соответственно этого слоя не будет да и все. А во view, где не нужно ничего считать и требуется только отобразить, возраст можно предоставлять уже посчитанным.

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