ТТУК - Толстые тупые уродливые контроллеры

[Adelf]

Выделять бизнес-логику в сервис стоит, когда она действительно ощущается. В форме регистрации бизнес-логики совсем чутьчуть. Почти во всех популярных компонентах веб-сайтов логика простая и её давление почти не ощущается на контроллерах.
Когда же делаешь веб- или десктоп-(неважно) приложение для каких-либо бизнес-задач логика сразу начинает давить и душа просит выделить ее в отдельный слой(иногда она реализуется хранимками на сервере, иногда еще до базы).
У меня сейчас проект и архитектура точь-в-точь как описал zerkms. Вот только репозитории работают с Oracle-объектами, а не linq. Там было очень важно выделить слой БЛ. Как итог мы получили возможность работать с разными СУБД(просто подменив репозитории, IoC-контейнеры тут хорошо помогли) и даже с разной реализацией бизнес-логики(было такое требование... возможность использовать другую, уже готовую систему)

 

[fixxxer]

Автор оригинала: zerkms
хехе, я в самом начале угу ещё сказал, что всё в жизни сложнее.

у меня в текущем проекте на работе иерархия такая:

- контроллер работает с сервисом
- сервис работает с репозиторием (репозиторий - это класс, который умеет извлекать данные, согласно всяких хитрых условий. причём он оперирует только условиями, о самом персистентном хранилище он не знает ничего)
- репозиторий работает с датаконтекстом (датаконтекст - у меня это datacontext из linq2sql, т.е. класс, который умеет сохранять данные непосредственно в хранилище, и извлекать согласно правилам, которые задали)

и сущности:
- linq2sql entities (сами сущности linq2sql, на которые отображаются записи БД)
- domain model entity (это сущность в терминах бизнес-логики)

Контроллеры/Сервис/Вьюшки оперируют DM Entity.
Репозиторий - знает о тех и других. При операциях извлечения конвертирует l2s E в DM Entity , при операциях модификации - наоборот.
Датаконтекст - работает только с l2s Entity.

Хехе. Как похоже. Но у меня попроще. "сущность" и есть "сервис". Есть модель (одна или несколько). У них всех общий Storage (набор значений, которым могут манипулировать как и сущность так и модели (опционально - через маппер, но он не очень часто нужен).

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

Пора расписывать новый паттерн, хе-хе.

 

[Sherman]

Автор оригинала: fixxxer
>>Я сейчас пришёл к варианту, когда к рядовым слоям MVC добавляется ещё один - сервисный слой (по факту там всё сложнее, но в общем виде именно так). Вот сервисный слой и содержит всю бизнес-логику.


о, ну хоть еще кто-то.

я про это год назад безуспешно втирал тут

-~{}~ 05.05.10 06:09:

хотя может и не про это. вот например редактирование профайла юзера как у тебя бы выглядело?

А нафига? Если в реальности у тебя не будет меняться имплементация(ну там использовали базу данных, а потом все на web services переписали), то это вроде бы лишнее?

p.s. А вообще это SOA-архитектура, которая в enterprise весьма распрастранена. Но там оно понятно, есть куча различных сервисов, либ и так далее. И все это может быть заменяемо. Поэтому этот зоопарк надо как-то гибко связывать(через интерфейс, а не реализацию).

-~{}~ 14.05.10 21:50:

Автор оригинала: zerkms
хехе, я в самом начале угу ещё сказал, что всё в жизни сложнее.

у меня в текущем проекте на работе иерархия такая:

- контроллер работает с сервисом
- сервис работает с репозиторием (репозиторий - это класс, который умеет извлекать данные, согласно всяких хитрых условий. причём он оперирует только условиями, о самом персистентном хранилище он не знает ничего)
- репозиторий работает с датаконтекстом (датаконтекст - у меня это datacontext из linq2sql, т.е. класс, который умеет сохранять данные непосредственно в хранилище, и извлекать согласно правилам, которые задали)

Не у тебя одного. Это похоже стандартный паттерн для SOA ;-)

Еще вспомнилось, что вообще говоря корни SOA гораздо глубже. То есть абстракция от имплементации это лишь побочный эффект. Суть же в том, что нужно проектировать программы, как standalone-сервисы. Это сказывается на api. Эти сервисы можно комбинировать между собой, и таким образом получить новые приложения. Но это все имеет серьезный оверхед, поэтому реально в этом нуждается довольно мало компаний.

Могу привести пример. В одной компании, где я ранее работал был например сервис passport. Он отвечал за авторизацию и аутентификацию юзеров на любых сервисах компании или на аффилированных сервисах третьих компаний. Также там был общий механизм регистрации и менеджмента пароля и профиля. Поддержка сессии между разными сервисами.