Лучший способ упаковать модуль Zend общего назначения - PullRequest
Новая
       26

Лучший способ упаковать модуль Zend общего назначения

3 голосов
/ 15 июля 2011

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

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

В основном, все, что нужно, чтобы поставить "zend on rails" и начать работу.Каков наилучший способ упаковки этих компонентов?Я вижу две возможности:

Как модули

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

Pro:

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

Con:

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

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

Мы помещаем его в библиотекуи укажите путь к классу.

Pro:

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

Con:

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

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

1 Ответ

1 голос
/ 15 июля 2011

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

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

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

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

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

...