Когда мы должны использовать многомодульную структуру (вместо простой структуры) в Php Phalcon?
Когда мы должны использовать многомодульную структуру (вместо простой структуры) в Php Phalcon?
Я нашел несколько многомодульных скелетов, таких как:
https://github.com/ovr/phalcon-module-skeleton,
https://github.com/phalcon/mvc/tree/master/multiple.
Но я не знаю, должен ли я использовать эту многомодульную структуру в проекте вместо использования нескольких проектов.
Что-то, о чем я могу подумать: более сложная конфигурация, сложная структура папок, мой веб-адрес будет длиннее (/ [module] / [controller] / [action]), и, что важно, производительность будет низкой (для большей загрузки, чем) ,
Тем не менее, я думаю, что в этом есть что-то интересное (так много ITer использовали это). Кто-то может дать мне преимущества, недостатки и критерии отбора.
P / s: та же проблема с модулем Zend2!
Решение
Если вы создаете одноцелевое приложение в виде API, который не использует Views, вам лучше использовать единую модульную структуру. Если это будет действительно простой API, например, для хранения / записи в журнал, то микро-приложение тоже подойдет.
Мультимодульная структура приложения полезна, если вы хотите создавать более сложные решения. Например, общедоступное приложение с общедоступным контентом, но с панелью администратора. Этот будет удобен для написания в нескольких модулях, чтобы отделить административные контроллеры / представления от этих общедоступных.
Моя привычка — использовать многомодульную структуру, потому что в основном мне приходится создавать приложения, которые являются CRM, с их API и общедоступной частью контента (например, документами). Для этого просто удобно создавать такие модули как:
- внешний интерфейс — для контроллеров, доступных каждому
- бэкенд — для контроллеров, доступных после аутентификации и авторизации, таких как административные функции
- API — для целей API;)
- общий — часть, которую я скорее не хочу реализовывать, но в одном проекте я вынужден поместить здесь некоторые абстрактные контроллеры, которые будут расширены в других модулях.
Таким образом, вы можете сохранить отдельную конфигурацию сервисов для каждого модуля, что избавит вас от обрезания вещей, которые вы используете при назначении модуля. , но не на модуле В. Как часть аутентификации — важно для бэкенд, но бесполезно для внешний интерфейс часть. Или Конфигурация базы данных — ведомые для внешнего интерфейса, ведущие для внутреннего и т. Д. Таким образом, это может быть также решение с точки зрения производительности для больших проектов.
Обновить
Иногда «мультипроект» — это вариант, включающий «мультимодульный» проект;) Это сильно зависит от того, чего вы пытаетесь достичь. Например. если вы разберете API, может быть проще масштабировать его на несколько экземпляров, но сначала вам придется потратить на настройку отдельного проекта.
Если предполагается, что система является экземпляром с одним сервером или каждый экземпляр должен быть абсолютно независимым от других экземпляров, достаточно будет одного многомодульного проекта — скажем, стандартной CMS, платформы блогов, даже простой браузерной игры или домашней страницы мобильного приложения, включая API для этого. Но если вы создаете целый универсум приложений, таких как внутренний API для приватного контента, CRM для управления им и несколько веб-страниц для обслуживания, хранить их как отдельные проекты будет проще в дальнейшем.
Другие решения
Ну, например, я в своем приложении я разделяю каждую функциональность — например, у меня есть модель Link — она разделяется на отдельный модуль, чтобы иметь хорошую структуру приложения, где каждая функциональность является отдельным модулем. Это как меньше классов для загрузки в загрузчике. Поскольку для загрузки всего приложения вам нужны только модели и маршруты из каждого модуля, вы загружаете в модуль другие вещи, такие как библиотеки / контроллеры / помощники / службы.