Является ли MVC + Service Layer распространенным в zend или PHP?

Ответ 1

Мартин Фаулер описывает "Уровень обслуживания" своей великолепной книги Шаблоны Архитектура корпоративных приложений. Если вам нравятся вопросы, подобные тем, которые вы задали, вы должны прочитать эту книгу.

Одно из моих соображений - управление транзакциями базы данных. Некоторые люди пытаются инкапсулировать запуск и совершение транзакций в своих моделях домена. Но тогда они запутываются, когда модели домена вызывают другие модели домена, которые также пытаются начать и совершить транзакции db. Итак, какая модель действительно принимает решение о совершении или откате транзакции? И что вы будете делать, если данная модель по-разному используется разными клиентами?

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

Что касается того, насколько это распространено, я не думаю, что это вообще вообще. Большинство людей, использующих Zend Framework (или любую другую инфраструктуру PHP или Ruby), только что перешли от "Активной записи" к новому блестящему, "Data Mapper решает все". Кажется, это сообщество изучает только один новый образец каждые пять лет. Они не дойдут до уровня обслуживания.

Re comment from @ktutnik:

Нет, шаблон Service Layer отличается от шаблона репозитория. Репозиторий - это абстрагирование доступа к базе данных, поэтому вы можете использовать базу данных, например, коллекцию. Уровень обслуживания - это инкапсуляция сложных операций приложения.

Другим способом думать о них является их связь с моделью домена. Репозиторий используется между моделью домена и базой данных. В то время как на уровне сервиса используется одна или несколько моделей доменов.

Service Layer --->  Domain Model(s) ---> Repository ---> DBAL

Ответ 2

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

• Возможности как службы помогают с масштабируемостью. Если у вас есть служба изображения, которая изначально использует локальную службу для ее работы, становится проще иметь эту точку обслуживания на другом сервере или какой-либо третьей стороне без необходимости делать быстрые обновления.

• Гибкость

  . На полпути через проект я решил изменить основную функциональность и смог сделать это безболезненно; позволяя мне быстро взвесить плюсы и минусы обновления. Эта гибкость полезна при быстром прототипировании и внушает определенную уверенность, потому что, если вам нужно пересмотреть что-то, это не будет кошмаром.

• расширяемость

  . Я уже определил службы в своем приложении, что я могу увидеть для других разработчиков или других виджетов, мобильных приложений в будущем. Теоретически это просто вопрос добавления аутентификации и авторизации для службы (потому что функции уже находятся в ее собственном слое, и мне не нужно тратить время, пытаясь отделить то, что я хочу выставить из остальной части кода).

• Службы легко добавлять и удалять (возможно, это относится к одной из ранних точек). У меня есть службы, специфичные для определенного этапа проекта (например, приглашение только на сцену), которые я могу удалить после завершения этой фазы.

Я думаю, что у него есть практические преимущества, и ключ к успеху в реализации - это хороший способ управлять услугами в приложении. Я использую symfony компонент инъекции зависимостей

Ответ 3

См. ZFEngine it cmf на ZF с реализацией уровня обслуживания