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

E>Мне интересно как это вообще можно поддерживать. Ведь мне зачастую чтоб дернуть какой метод, нужно сделать это в контексте транзакции.
Не хочу никого задеть. Но когда пишешь только Web проекты вида запрос-ответ, то оно кажется именно так. Когда тебе нужна одна и та же логика в нескольких слабо связаных звеньях приложения, то смотрится всё в ином свете. У меня сейчас GUI, Business Transaction, Cross-server Data Synchronization. Они друг с другом не пересекаются. 1й работает на клиенте, второй на сервере, третий на отдельном сервере. И всем нужно использовать одну и ту же бизнес-логику, которая просто вычисляется из свойсв бизнес-сущностей. Нафиг мне транзакция для вычисления состояния объекта?

E>А то и чтоб AOP обертка какая дергалась. Что, в Entity спрингом инжектить сервис чтоль? Я видел такое когда то в одном проекте — ужас! А логика то весьма может навороченная быть.
Что-то тебя понесло не в ту степь.

E>И если метод вычисления возраста еще имеет смысл в сам класс Entity добавить, то метод рассчета каких нидь процентов по кредиту — это по любому внешний сервис, если ты не враг себе. Ибо для рассчета этих процентов возможно потребуется сделать запрос через 10 различных вебсервисов, чтоб это не тормозило, еще и кучу кеширования делать — это явно не в Entity пихать нужно. И сервис слой по любому будет.
У меня масса методов, которые вычисляются по состоянию сущности. И в зависимости от состояния, тот или иной слой принимает решение. Никакие транзакции там не нужны.

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

E>Я не очень понимаю необъодимость отдельных бинов для бизнес логики, отличных от ORM. Соответственно этого слоя не будет да и все. А во view, где не нужно ничего считать и требуется только отобразить, возраст можно предоставлять уже посчитанным.
Это не я придумал. Это в статье написано.

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