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

E>А может не нужно фигачить бизнес методы прямо в Entity?
Зачастую надо. Иначе можно свалиться в полностью Anemic модель, с такими косяками как
— монструозными вычислениями в Service с нарушением инкапсуляции (внутри классов та же логика выглядит, читается и поддерживается проще)
— необходимостью таскать за собой Service везде где вообще нужна логика — интерцеторы, GUI и пр.

E>А как нидь разграничить логику. Entity для храниния, DTO для для передачи, а бизнес логику помещать в отдельные классы что то типа EntityService.
Service это паттерн TransactionScript. Там живут бизнес транзакции. Вынос вообще всей логики из бизнес-объектов в Service приводит к трудно четаемому и слабо переиспользоваемому коду. И ещё к процедурному стилю.

E>Да, если приложение тривиальное, то кода будет больше. Но в среднем и крупном приложении от этого будет весьма неслабая выгода.
Тут походу каждый думает что у него не тривиальное крупное приложение, а у остальных поделка на коленке?

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