PHP Lang
  1. PHP Lang
  3. Когда мы должны использовать многомодульную структуру (вместо простой структуры) в php Phalcon
Intereting Posts
select и echo одно поле из mysql db, используя PHP Повторно ввести $ HTTP_POST_VARS в PHP 5.3 codeigniter Disallowed Key Characters error PHP rsa получает открытый ключ из файла pem Как определить, содержит ли строка символы на иврите, используя PHP? URL переписывания в PHP с помощью WordPress Laravel TokenMismatchException Как узнать, какие IP-адреса имеют мои серверы? Чат в реальном времени, обработка сообщений – Socket.io, PHP, MySQL, Apache Почему я получаю массив объектов SimpleXMLElement здесь? Плохой фильтр регулярных выражений слов не работает Как получить базовое доменное имя из URL с помощью PHP? вызов функции php с использованием ajax после интервала времени Перенаправление URL-адресов, не относящихся к WWW-WWW Запрос многих номеров отслеживания с помощью Fedex SOAP API с PHP

Когда мы должны использовать многомодульную структуру (вместо простой структуры) в php Phalcon

Когда мы должны использовать многомодульную структуру (вместо простой структуры) в php Phalcon?

Я нашел несколько многомодульных скелетов, таких как:

https://github.com/ovr/phalcon-module-skeleton ,

https://github.com/phalcon/mvc/tree/master/multiple .

Но я не знаю, должен ли я использовать эту многомодульную структуру в проекте вместо использования нескольких проектов. Что-то, о чем я могу думать, это: более сложная конфигурация, сложная структура папок, мой веб-url будет длиннее (/ [module] / [controller] / [action]), и, что важно, производительность будет низкой (для большей загрузки вещей, чем) ,

Тем не менее, я думаю, что есть что-то интересное (так много ITER использовали). Кто-то может дать мне преимущества, недостатки и критерии отбора.

P / s: та же проблема с модулем Zend2!

Если вы создаете одноцелевое приложение как API, который не использует Views, вы должны использовать структуру единого модуля. Если это будет очень простой API, например, для хранения / регистрации, будет выполнено и микроприложение.

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

Моя привычка заключается в использовании многомодульной структуры, потому что в основном мне приходится создавать приложения, которые являются CRM с их API и общедоступной частью контента (например, docs). Для этой цели просто создать такие модули, как:

  • frontend – для контроллеров, доступных для всех
  • backend – для контроллеров, доступных после аутентификации и авторизации, таких как административные вещи
  • API – для целей API;)
  • common – часть, которую я скорее не желаю реализовывать, но в одном проекте я вынужден поставить здесь несколько абстрактных контроллеров, которые будут расширены в других модулях.

Таким образом, вы можете сохранить отдельную конфигурацию служб для каждого модуля, что избавит вас от необходимости отключать то, что вы используете в целях модуля A , но не на модуле B. Как часть аутентификации – важна для бэкэнд , но бесполезная для сторонней части. Или конфигурация базы данных – подчиненные устройства для интерфейса, мастер для бэкэнд и т. Д. Таким образом, это может быть также решение для больших проектов.

Обновить

Иногда «multi-project» – это опция, включающая «мультимодульный» проект;) Это сильно зависит от того, чего вы пытаетесь достичь. Например. если вы отбросите API в отдельности, может быть проще масштабировать его по нескольким экземплярам, ​​но вначале вам стоит создать отдельный проект.

Если система должна быть односерверным экземпляром, или каждый istance должен быть абсолютно независим от других экземпляров, одного многомодульного проекта будет достаточно – скажем, стандартная CMS, платформа блога, даже простая браузерная игра или домашняя страница мобильного приложения, включая API для этого. Но если вы создаете целый универсум приложений, таких как внутренний API, чтобы лидировать контент, CRM управляет им и несколькими веб-страницами, чтобы обслуживать его, сохраняя их в виде отдельных проектов, будет легче управлять позже.

Ну, например, я в своем приложении разбиваю каждую функциональность – например, у меня есть модель Link – она ​​разделена на отдельный модуль, чтобы иметь хорошую структуру приложения, где каждая функциональность является разделенным модулем. Это как меньше классов для загрузки в загрузчик. Beacause вам нужны только модели и маршруты из каждого модуля для загрузки всего приложения, и вы загружаете в модуль другие вещи, такие как библиотеки / контроллеры / помощники / службы.