Как стать автором
Обновить

Комментарии 12

Когда я искал по поводу необходимости реализации слоя DAO для ORM фреймворков типа Hibernate, то наткнулся на просто жесточайшией холивары по этому вопросу. Пока придерживаюсь мнения, что слой DAO нужно делать. Когда на практике обкатают теория без DAO, тогда и посмотрим.
Не знаю, по моему схема, описанная в этом посте, это классический подход.
А совмешать CRUD с Hibernate — извращение, потому что тогда не понятно зачем вообще Hibernate.
Хорошая статья, всё по делу. Кстати, а стоит ли вообще делать PostId в посте? Мне кажется, это подробности базы.
С NHibernate я обычно не делаю Id (если нужно на Web, можно запросить у репозитория).

Ещё я не совсем согласен, что в доменных сервисах нет собственной логики.
Мне кажется, что если следовать SRP, нельзя все задачи помещать в домен.
> Кстати, а стоит ли вообще делать PostId в посте? Мне кажется, это подробности базы.

Тоже думал над этим. Но лучше решения не придумал. Решил, что некий объект ссылка с отношением один-к-одному должен быть, потому как его проще таскать на верхних уровнях приложения, нежели весь объект.

>С NHibernate я обычно не делаю Id (если нужно на Web, можно запросить у репозитория).

А можно по-подробней?

>Ещё я не совсем согласен, что в доменных сервисах нет собственной логики.

В сервисом не должно быть только логики домена, а своя собственная логика вполне может быть. Насколько я знаю такую логику называют application logic.

>>С NHibernate я обычно не делаю Id (если нужно на Web, можно запросить у репозитория).
>А можно по-подробней?

Ну если это не web, то id не нужен вообще, потому что identity map.
Если web, то либо у репозитория GetKey(entity), либо отдельный KeyService.

Про логику согласен, но тогда не вижу необходимости в тех сервисах, которые просто middle men.
> В конечном итоге для себя решил так: ничего плохого в anemic нету, но это процедурный подход со всеми вытекающими последствиями.
Не вижу в ADM ничего процедурного (в смысле не объектного) — она всего лишь следствие использования SRP при реализации персистентности.
У меня есть маленькое подозрение, что вы путаете с ActiveRecord=) И ADM, и RDM соответствуют принципу SRP в реализации персистентности, а именно они ничего «не знают» о персистентности.

Есть более или менее устоявшееся мнение, что любая сущность характеризуется 3 свойствами: идентичностью, состоянием и поведением. ADM — это идентичность + состояние, в этом и заключается ее «недообъектность». Можете у Фаулера про Transaction script почитать — это как раз типичный прием реализации бизнес-логики с применением ADM.
>У меня есть маленькое подозрение, что вы путаете с ActiveRecord
Не путаю.
>ADM — это идентичность + состояние, в этом и заключается ее «недообъектность».
Нет — в данном случае предельно упрощенное поведение (тривиальный доступ к состоянию) есть сознательное решение с целью упрощения реализации персистентности: объект, который может пережить программу, по определению должен иметь представление в виде данных и только данных. Если он и в «живом» виде будет только данными, то персистентность реализуется тривиально, в противном же случае — задача не имеет общего решения даже в виде монструозных фреймворков. Это не процедурный подход, а объектный. Да, такой результат можно получить и с процедурным, но приведет к нему совсем другой путь. Точно так же как процедура в рамках объектного подхода — это объект без состояния, но с поведением.
В общем случае у сущности могут быть все три свойства — но любая из них (кроме ИМХОидентичность) не является необходимой (точнее, необходимой в нетривиальном виде) для каждого конкретного экземпляра.
В целом у «худых» сущностей есть некие зачатки объектности: поведение заключается в инкапсуляции состояния. Однако я считаю это притягиванием за уши. Я против того, что бы процедуру называть объектом без состояния — для меня это всегда просто процедура, а объект без поведения для меня в голове это просто record или struct. При использовании «худых» моделей для реализации бизнес-логики не обойтись без написанию процедур. ADM вынуждает писать процедуры (Transaction scripts, Flat Service Layers и прочие красивые слова для обозначения банальных процедур), именно поэтому я назвал ее процедурным подходом.

Что касается реализации персистентности. Я так и не понял что же за проблемы могут быть при сохранении толстых моделей и какие нужны для этого монструозные фреймворки. Может быть вы имеете ввиду Dependency Injection, с помощью которых нужно подтягивать сервисы в модели? Согласен, что такое желание может возникать, однако это противоречит идеям DDD — слой домена ничего не должен знать ни о персистентности, ни о сервисах, что бы соблюдался тот самый SRP. По «дзену» всю внешнюю логику нужно вытаскивать из моделей в отдельные сервисы.

Я думаю корни анемичной модели скорее всего идут к потребности написания большого количества кода с логикой типа CRUD. В этом случае у бизнес-сущностей единственное поведение это действительно хранение состояния. В приложениях, где много инфраструктурной логики anemic так же оптимальный выбор.
> Однако я считаю это притягиванием за уши. Я против того, что бы процедуру называть объектом без состояния — для меня это всегда просто процедура, а объект без поведения для меня в голове это просто record или struct
Это уже психологический барьер. Объект без поведения — это совсем не обязательно struct. Объект никому и никогда не дает доступа к своим полям иначе как через методы доступа. И объектом без поведения он является тогда и только тогда, когда внутреннее состояние целиком определяется и наблюдается внешним, т.е. методов доступа (свойств) достаточно для установки и наблюдения полного состояния и ни в каких других объект не нуждается. При этом само внутреннее состояние может храниться иначе чем внешнее (например, в сжатом виде). Структура — это лишь эмуляция такого объекта с ограниченными возможностями (внутреннее состояние физически совпадает с внешним, а не просто однозначно соответствует ему).
>Я так и не понял что же за проблемы могут быть при сохранении толстых моделей и какие нужны для этого монструозные фреймворки.
Уже в приведенном примере есть проблема — грузить ли комментарии вместе с постом, решение которого выливается либо в геморрой с ленивой загрузкой либо в тормоза, если комментариев много. Объектно-реляционный импеданс для «толстой» модели проявляется в всей красе, а для «худой» — минимален.
мне кажется, или код превратился во что-то нечитаемое в этом посте?
Забавно. Давайте использовать Repository и тогда вам не нужен update :) А если все таки нужно обновить пост?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории