Лучший способ упаковать универсальный модуль zend

Поскольку наша компания начинает использовать Zend Framework в качестве базовой структуры для большинства наших проектов, мы хотим использовать некоторые общие элементы во всех наших проектах. Я говорю о таких вещах, как:

  • Реализация модели (на основе doctrine2)
  • RBAC для модели, включая пользователя, группу, ролевые модели
  • Механизм создания шаблонов на основе xml для бэкэнд-интерфейсов ajax
  • (вы называете это) ...

В принципе, все поставить «зенд на рельсы» и приступить к работе. Как лучше всего упаковать эти компоненты? Я вижу две возможности:

В виде модулей

Включаем необходимые функции отдельными модулями в папку модулей.

Pro:

  • Мы можем устанавливать маршруты и выполнять код, что хорошо для многих модулей (воображаемый пример: модулю PayPal нужен какой-то URL-адрес обратного вызова. Если наш модуль может настроить его самостоятельно, настройка от «разработчика проекта» не требуется) .
  • Мы можем предоставить реальную функциональность (например, администрирование пользователей) из коробки
  • У нас есть бутстрап для настройки автозагрузки, доктрины и т. Д.

Против:

  • Плохое место? Мешает проекту пользователей
  • Немного сложнее делиться между проектами (подмодули git вместо пути к классам)

В папке библиотеки

Мы кладем его в папку библиотеки и указываем на него путь к классам.

Pro:

  • Чистое решение
  • Совместное использование в проектах

Против:

  • Bootstrap должен быть явно вызван
  • Никакой прямой маршрутизации или действий - все должно быть проксировано через конкретный проект

Итак, как решить эту проблему? Куда вы помещаете в zf многоразовые вещи общего назначения?


person Steffen Müller    schedule 15.07.2011    source источник


Ответы (1)


Я думаю, вам следует использовать оба подхода.

При разработке «библиотечного» кода, например, «инфраструктурных» классов и других вещей, которые можно использовать повторно (например, собственных компонентов ZF, компонентов Doctrine 2 и т. д.), вы можете поместить их в библиотеку. каталог. (или собственный, совершенно отдельный проект)

При разработке реальных модулей ZF (например, модуля аутентификации) форматируйте код вокруг структуры модуля ZF.

Я думаю, что, используя такой подход, вы получите все преимущества, которые вы перечислили, и почти ничего из минусов :)

В качестве одной дополнительной идеи, если вы разрабатываете части своей архитектуры как «службы», вы даже можете сохранить их работающими как их собственные конечные точки веб-служб.

person Jani Hartikainen    schedule 15.07.2011