Организация кода нескольких приложений Zend

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

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

Я стараюсь держать его настолько разъединенным, насколько это логично, поэтому через 12 месяцев, когда мое время истечет, у любого, кто придет, не будет проблем с распространением того, что я произвел.

Пример структуры:

applicationStorage\ (contains all applications and associated data)
applicationStorage\Applications\ (contains the applications themselves)

applicationStorage\Applications\external\ (application grouping folder) (contains all external customer access applications)
applicationStorage\Applications\external\site\ (main external customer access application)
applicationStorage\Applications\external\site\Modules\ 
applicationStorage\Applications\external\site\Config\
applicationStorage\Applications\external\site\Layouts\
applicationStorage\Applications\external\site\ZendExtended\ (contains extended Zend classes specific to this application example: ZendExtended_Controller_Action extends zend_controller_Action )
applicationStorage\Applications\external\mobile\ (mobile external customer access application different workflow limited capabilities compared to full site version)

applicationStorage\Applications\internal\ (application grouping folder) (contains all internal company applications)
applicationStorage\Applications\internal\site\ (main internal application)
applicationStorage\Applications\internal\mobile\ (mobile access has different flow and limited abilities compared to main site version)

applicationStorage\Tests\ (contains PHP unit tests)

applicationStorage\Library\
applicationStorage\Library\Service\ (contains all business logic, services and servicelocator; these are completely decoupled from Zend framework and rely on models' interfaces)
applicationStorage\Library\Zend\ (Zend framework)
applicationStorage\Library\Models\ (doesn't know services but is linked to Zend framework for DB operations; contains model interfaces and model datamappers for all business objects; examples include Iorder/IorderMapper, Iworksheet/IWorksheetMapper, Icustomer/IcustomerMapper)

(Примечание: папки Modules, Config, Layouts и ZendExtended дублируются в каждой папке приложения; но я их опустил, поскольку они не нужны для моих целей.)

Для библиотеки это содержит весь «универсальный» код. Фреймворк Zend лежит в основе всех приложений, но я хотел, чтобы моя бизнес-логика была независимой от Zend-фреймворка. Все интерфейсы модели и картографа не имеют публичных ссылок на Zend_Db, но на самом деле обернуты вокруг них конфиденциально.

Так что я надеюсь, что в будущем я смогу переписать mappers и dbtables (содержащие Models_DbTable_Abstract, который расширяет Zend_Db_Table_Abstract), чтобы отделить мою бизнес-логику от инфраструктуры Zend, если я хочу переместить свою бизнес-логику (сервисы) в среда среды не Zend (может быть, какая-то другая среда PHP).

Используя serviceLocator и регистрируя необходимые службы в начальной загрузке каждого приложения, я могу использовать разные версии одного и того же сервиса в зависимости от запроса и того, к какому приложению обращаются.

Пример: для всех внешних приложений будет зарегистрирован service_auth_External, реализующий service_auth_Interface.

То же самое с внутренними приложениями с Service_Auth_Internal, реализующим service_auth_Interface Service_Locator :: getService ('Auth').

Я обеспокоен тем, что могу упустить некоторые возможные проблемы с этим.

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

Если у кого-то есть какие-либо предложения, я был бы очень признателен.

Я использовал контекстное переключение для функций AJAX в отдельных приложениях, но есть большая вероятность, что для них будут созданы веб-сервисы как внешние, так и внутренние. Опять же, они будут разделены из-за авторизации и различных доступных услуг.

\applicationstorage\Applications\internal\webservice 
\applicationstorage\Applications\external\webservice

В конечном счете, некоторый код будет специфичным для «бизнес-логики» вашего приложения, а другой - «библиотечный код». Например, то, что проверяет ввод данных в форму, обычно можно рассматривать как «библиотеку», тогда как то, что помогает вам рассчитать предложения, доступные для клиента X в конкретном месяце, является явно «бизнес-логикой».

Это скорее проблема контроля версий, и есть много способов, которыми вы можете обшарить эту конкретную кошку. Такие инструменты, как Maven (и в некоторой степени Phing / Ant) созданы для сборки приложений из различных разнородных источников - на основе какого-то внешнего файла конфигурации (обычно XML). Это означает, что вы можете поддерживать отдельные репозитории для библиотечного кода и импортировать его в Приложение X, если вам это нужно.

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