Re[2]: True OOP&Repository vs Service&AnemicModel
От: Blazkowicz Россия  
Дата: 24.10.07 18:44
Оценка:
Здравствуйте, Igor Trofimov, Вы писали:

iT>Не знаю, как насчет новой... Repository был описан в книжке Фаулера по архитектуре в 2003 г.

Разве? Не припомню. И с сайта Фаулера этот паттерн ссылается на книгу Domain Driven Design, а не Enterprise Patterns.

iT>"Anemic Domain" Фаулер ругает потому, что логика, природно связанная с бизнес-объектами, выносится куда-то еще, как следствие — повторяется, и получается что-то близкое к процедурному подходу (можете назвать это SOA, легче не станет).

В случае Anemic Domain, в модель пихается только та логика которая модет быть ограничена строго этой моделью. Такой логики, обычно, в проектах не так много.

iT>Если вы разделите бизнес-логику на логику домена и логику приложения, то станет видно, что первая — да, должна быть внутри, а вот вторая может быть и выставлена как сервис.

Не очень понял. Логика которая обращается к DAL, она какая из двух?

iT>DAL — это не совсем внешний сервис, это скорее "внутренний сервис", он ближе к данным и, в принципе с ним могут работать и сами бизнес-объекты. Впрочем, тут есть разные подходы.

Да, могут, для этого делается абстракция "репозиторий". Только я хочу понять в чем кайф от такого подхода?

iT>Repository — тот, вроде, вообще ортогонален проблеме Anemic Domain — он может применяться как в anemic domain, так и в rich domain. Он позволяет бизнес-логике формулировать "объектные запросы", запросы на выборку бизнес-объектов определенного типа по структурированно заданным критериям. За счет этого связь между DAL и бизнес-логикой становится не такой жесткой, развязывается через Repository.

Попробую переосознать завтра утром, сейчас все равно не пойму в чем прелесть. И что такое "объектные запросы" и как они связаны с Repository.

iT>Очевидный минус — Repository сложно сделать одинаково эффективным для любых выборок. Ручной SQL все равно будет гибче и мощнее и быстрее.

Брр, про SQL речь вообще не идет. Понятно что бизнес запросы транслируются в SQL через несколько слоев, точто так же понятно что бизнес логика не формирует запросы. Этим занимается DAL, вот только в чем глубинный смысл репозитория в этом процессе, кроме ослабления связи?

iT>Все вышесказанное — довольно IMHO

ОК. Спасибо за мнение, но все равно света в конце тунеля пока не видно.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.