Вероятно, вы слышали о различии Fat Model / Thin Controller vs. Thin Model / Fat Controller. Недавно я слышал, что у вас может быть что-то среднее между тем, где часть логики модели входит в сервисный уровень. Насколько распространено это? и знаете ли вы (или можете думать) о каких-либо реальных примерах, иллюстрирующих это?
Мартин Фаулер описывает шаблон Service Layer его большой книги « Шаблоны архитектуры корпоративных приложений» . Если вам нравятся вопросы, подобные тем, которые вы задали, вы должны прочитать эту книгу.
Одно из моих соображений – управление транзакциями базы данных . Некоторые люди пытаются инкапсулировать запуск и совершение транзакций в своих моделях домена. Но тогда они запутываются, когда модели домена вызывают другие модели домена, которые также пытаются начать и совершить транзакции db. Итак, какая модель действительно принимает решение о совершении или откате транзакции? И что вы будете делать, если данная модель по-разному используется разными клиентами?
Уровень сервиса – это решение для этого, потому что это уровень, на котором вы можете запускать и выполнять работу, которая включает в себя несколько моделей доменов.
Что касается того, насколько это распространено, я не думаю, что это вообще. Большинство людей, использующих Zend Framework (или любую другую инфраструктуру PHP или Ruby), только что перешли от «Активной записи» к новому блестящему, «Data Mapper решает все». Кажется, это сообщество изучает только один новый образец каждые пять лет. Некоторое время они не дойдут до уровня обслуживания.
Re comment от @ktutnik:
Нет, шаблон Service Layer отличается от шаблона репозитория. Репозиторий – это абстрагирование доступа к базе данных, поэтому вы можете использовать базу данных, например, коллекцию. Уровень обслуживания – это инкапсуляция сложных прикладных операций.
Другой способ думать о них – это их связь с моделью домена. Репозиторий используется между моделью домена и базой данных. В то время как на уровне сервиса используется одна или несколько моделей доменов.
Service Layer ---> Domain Model(s) ---> Repository ---> DBAL Адвокация уровня обслуживания является относительно новой и по-прежнему подвержена множеству интерпретаций. Я думаю, что это означает наличие слоя, который использует несколько доменных моделей, которые управляют контроллерами (я могу, однако, упростить его). Недавно я разработал веб-сайт с использованием этих и практических преимуществ, с которыми я столкнулся:
Функции как службы помогают с масштабируемостью. Если у вас есть служба изображений, которая изначально использует локальную службу для выполнения ее работы, становится проще иметь эту точку обслуживания на другом сервере или какой-либо третьей стороне, не делая резких обновлений
Гибкость. На полпути через проект я решил изменить основную функциональность и смог сделать это безболезненно; позволяя мне быстро взвесить плюсы и минусы обновления. Эта гибкость полезна при быстром прототипировании и внушает определенную уверенность, потому что, если вам нужно что-то пересмотреть, это не будет кошмаром.
Расширяемость. Я уже определил службы в своем приложении, что я могу увидеть для других разработчиков или других виджетов, мобильных приложений в будущем. Теоретически это просто вопрос добавления аутентификации и авторизации для службы (потому что функции уже находятся в собственном слое, и мне не нужно тратить время, пытаясь отделить то, что я хочу открыть из остальной части кода ).
Службы легко добавлять и удалять (возможно, это относится к одной из ранних точек). У меня есть службы, относящиеся к определенному этапу проекта (например, приглашаю только этап), который я могу сбросить, как только эта фаза закончится.
Я думаю, что у этого есть практические преимущества, и ключ к успеху в реализации имеет хороший способ управлять услугами в приложении. Я использую компонент инъекции зависимостей symfony
См. ZFEngine, это cmf на ZF с реализацией уровня сервиса