Проблема терминологии
Понятия «модульной структуры приложения» в целом и «модуля» в частности определить не так легко как это может показаться на первый взгляд. Вот как звучит определение модульной структуры в официальном руководстве к Zend Framework:
Определенная соглашением модульная структура директорий позволяет разделять различные приложения MVC (Model-view-controller) в автономные единицы и повторно использовать их с различными фронт-контроллерами.
Пример такой структуры из руководства:
Однако, с другой стороны, на практике в разработке веб-приложений часто используется подход разделения функционала по принципу front-end/backend, когда управляющий код отделяется от остального (часто даже разрабатывается другой командой разработчиков). Такой же точно подход нередко применяется и при разработке проектов на основе ZF – весь backend проекта (часто так называемая «админ часть») оформляется в виде отдельного модуля, и содержит контроллеры, которые отвечают за "административную часть" модулей. Достоинство такого подхода – простота и очевидность реализации (не требуется никаких дополнительных действий), своеобразная «привычность» такой схемы. Недостаток – необходимость совершать массу дополнительных телодвижений при желании перенести код какого-то конкретного модуля целиком в другой проект.
Понятия «модульной структуры приложения» в целом и «модуля» в частности определить не так легко как это может показаться на первый взгляд. Вот как звучит определение модульной структуры в официальном руководстве к Zend Framework:
Определенная соглашением модульная структура директорий позволяет разделять различные приложения MVC (Model-view-controller) в автономные единицы и повторно использовать их с различными фронт-контроллерами.
Пример такой структуры из руководства:
Код:
Из этого определения можно заключить, что модуль как структурная единица приложения должен обладать максимальной транспортабельностью и независимостью от других модулей приложения и содержать в себе весь функционал, относящийся к этому модулю. Плюсом такого подхода к проектированию является настоящая универсальность компонентов приложения и предпосылки к созданию собственной мощной и гибко конфигурируемой системы управления контентом. Главный минус же – весьма неочевидная реализация. | docroot/ |
| index.php |
| application/ |
| default/ |
| controllers/ |
| IndexController.php |
| FooController.php |
| models/ |
| views/ |
| scripts/ |
| index/ |
| foo/ |
| helpers/ |
| filters/ |
| blog/ |
| controllers/ |
| IndexController.php |
| models/ |
| views/ |
| scripts/ |
| index/ |
| helpers/ |
| filters/ |
| news/ |
| controllers/ |
| IndexController.php |
| ListController.php |
| models/ |
| views/ |
| scripts/ |
| index/ |
| list/ |
| helpers/ |
| filters/ |
Однако, с другой стороны, на практике в разработке веб-приложений часто используется подход разделения функционала по принципу front-end/backend, когда управляющий код отделяется от остального (часто даже разрабатывается другой командой разработчиков). Такой же точно подход нередко применяется и при разработке проектов на основе ZF – весь backend проекта (часто так называемая «админ часть») оформляется в виде отдельного модуля, и содержит контроллеры, которые отвечают за "административную часть" модулей. Достоинство такого подхода – простота и очевидность реализации (не требуется никаких дополнительных действий), своеобразная «привычность» такой схемы. Недостаток – необходимость совершать массу дополнительных телодвижений при желании перенести код какого-то конкретного модуля целиком в другой проект.
давно это сидит в голове.
