Используйте Zend Framework для создания гибкого базового приложения

Question

Мы разрабатываем платформу для электронной коммерции, используя Zend Framework. У нас есть несколько экземпляров приложения, запущенных и работающих с использованием одной и той же базы кода. Настройки конфигурации используются для того, чтобы различать различные магазины.

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

Есть ли у кого-нибудь опыт такого подхода? Есть ли лучшие практики вокруг?

Любые указатели очень ценятся!

Answer 1

Я недавно рассматривал ту же проблему в своем агентстве, и решение, которое я сейчас тестирую, включает следующую структуру папок приложения:

app/
    default/
            controllers/
            models, etc
    ecommerce/
              controllers/
              models, etc
lib/
    S24/
        ComponentCode.php
modules/
        ecommerce/
                  admin/
                        controllers/
                        models, etc
                  default/
                          controllers/
                          models, etc
data, public web, temp, other ZF folders

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

Папки lib/S24 и modules/ecommerce будут общими и одинаковыми для каждого проекта (мы SVN выводим эти папки наружу).

app - это каталог модулей, поэтому папки default и ecommerce создают модули в ZF. app/default для контроллеров по умолчанию (т.е. без модуля). app/ecommerce будет содержать набор контроллеров, которые просто расширяют контроллеры в пределах modules/ecommerce/default/controllers.

Затем вы можете расширить функциональность в app/ecommerce/controllers, если хотите, или добавить новую функциональность.

Поскольку мы хотим, чтобы система администрирования модуля оставалась неизменной, а также поддерживала несколько систем администрирования (по URL-адресам, таким как www.domain.com/admin/ecommerce и www.domain.com/admin/user), мы обслуживаем модульную систему администрирования прямо из папки modules. Любые пользовательские страницы администратора могут быть добавлены к app/admin/controllers.

// Add Controller folder
$front->addControllerDirectory('/path/to/modules/ecommerce/admin/controllers', 'ecommerceAdmin');

// Add route
$router->addRoute(
    'ecommerceAdmin',
    new Zend_Controller_Router_Route('admin/ecommerce/:controller/:action',
                                     array('module' => 'ecommerceAdmin', 
                                           'controller' => 'index',
                                           'action' => 'index'))
);

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

Answer 2

РЕДАКТИРОВАТЬ: я не заметил различные комментарии. Таким образом, настроенный код находится не в одном пакете, он добавляет функциональность и не переопределяет.

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

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

То, как я использую автозагрузку PHP (см .: Как ООП удается «включать» классы, хранящиеся в разных файлах ), создает отдельные папки в зависимости от имени класса. Это может быть полезно для отделения кода от других реализаций.

Answer 3

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

Что касается работы с пользовательской функциональностью (кодом), то, если она полностью сделана на заказ, то я думаю, что имеет смысл модульно или упаковать пользовательский код в контейнер, на который может ссылаться уникальный идентификатор клиента, и загружать код по запросу. Это просто для модулей, но, очевидно, сложнее, если вам нужны отдельные контроллеры или даже действия.

Некоторые системы встраивают свою собственную систему событий / обратных вызовов, которая позволяет вводить функциональные возможности, хотя это более распространено для общедоступных API.