Zend Framework MVC Design

Question

Я также задавал этот вопрос на zfforums, но, возможно, я получу ответ здесь.

Таким образом, Zend Framework является универсальной, гибкой, плохо связанной, высококачественной средой общего назначения. Однако я нахожу некоторые части MVC несовместимыми и чрезмерно сложными. Надеемся, что некоторые из вас смогут обосновать некоторые решения ZF и ответить на несколько вопросов:

Общие вопросы / комментарии

1. Почему Zend MVC не следует тем же соглашениям об именах, что и другие компоненты Zend? Например, mvc использует строчные буквы, множественные имена каталогов и имена классов не имеют префикса с информацией о каталоге, поэтому их нелегко загрузить автоматически.

2. Мне бы хотелось добавить корневую директорию модуля. Таким образом, мне не пришлось бы явно настраивать диспетчер, добавляя каталоги контроллера / модуля. Я мог бы зайти в модуль и получить его доступ немедленно.

3. Почему существует различие между помощниками вида и действия? В настоящее время помощники не предназначены для совместного использования в коде, и существуют несовместимые методы загрузки и доступа к помощникам. Другие фреймворки позволяют вам совместно использовать одни и те же помощники в любом месте вашего кода. Я не вижу необходимости специализироваться и нарушать СУХОЙ.

Zend Просмотр вопросов

1. Почему представления используют «$ this» для доступа к ресурсам? Я не вижу необходимости в дополнительной печати. Некоторые другие фреймворки извлекают () массив переменных представления и позволяют загружать глобальные функции или автозагрузку статических помощников из представления: myHelper :: someMethod ();

2. Почему помощники вида допускают только одну функцию на класс? Это приводит к большому количеству классов и связанному обслуживанию. Я бы предпочел статические классы с любым количеством методов, как уже упоминалось.

Answer 1

Я использую Zend Framework в огромном интранет-сайте, так как он на ранних стадиях, 0,3 или 0,4, я думаю, и я следовал большинству решений относительно ваших вопросов. Я попытаюсь объяснить их немного:

1. В большинстве случаев вам не нужно использовать модули. Вы можете поместить все свои контроллеры в каталог application/default, назвать их IndexController или HelpController и все готово, просто получите доступ к http://www.domain.com/ или http://www.domain.com/help.

   Если ваш проект начинает расти, вы можете добавлять модули по своему желанию, добавляя к ним префикс с именем модуля (имя каталога) Admin_IndexController или Forum_PostController, заменяя их на http://www.domain.com/admin (вы находитесь в admin модуль, index контроллер; не в default модуль / admin контроллер).

2. Например, вы можете установить каталог модулей на applicatoin/modules и настроить FrontController для поиска в этом каталоге модулей. Использование addModuleDictory Всякий раз, когда вы создаете новый каталог и помещаете туда свои контроллеры / представления, они автоматически обнаруживаются диспетчером. Здесь является примером.

3. Как я вижу, они служат явно различным целям. ViewHelpers используются для генерации разметки и визуализации других действий непосредственно в представлении, создания абстрагируемого меню, боковой панели и т. Д. OTOH ActionHelpers взаимодействует с процессом диспетчеризации, позволяя вам перенаправить, например, другое действие.

Просмотры

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

2. По главной причине того, что в одном файле нельзя использовать более одного контроллера: автозагрузка. Когда вы используете $this->someViewHelper(), базовый движок ищет класс с именем *_SomeViewHelper_Helper в ваших путях плагинов. Другая причина заключается в том, что статические классы очень сложны для модульного тестирования. Есть даже предложение переписать FrontController как экземплярный класс, а не как Singleton.

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

В конце я думаю, что ZF - это очень надежная структура, дающая нам свободу делать то, что мы хотим.

Я надеюсь, что смогу помочь вам разобраться с вашими вопросами.

Answer 2

Я не знаю всех ответов на эти вопросы, но это интересные вопросы, поэтому я сделаю удар и, надеюсь, кто-нибудь сможет заполнить пробелы.

Общее

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

2. Вы можете изменить диспетчер или написать плагин для сканирования каталогов и добавления их.

3. Здесь определенно есть совпадение - URL-помощники являются хорошим примером этого. Обычно помощник вида генерирует разметку, поэтому я думаю, что есть достаточно большое различие.

View

1. Я не знаю точную причину, но я предполагаю, что это позволяет другим помощникам и функциональности просмотра работать вместе легче Например, если вы использовали помощник doctype для установки типа документа, помощники элемента формы могут сгенерировать XHTML или HTML в зависимости от ситуации.

2. Это определенно приводит к большому количеству уроков, но я не уверен насчет обслуживания. Я не сталкивался с какими-либо проблемами. Я вижу использование в статических классах, но помните, что Zend_View не помешает вам их использовать. Если у вас есть статические классы в вашем пути включения (и вы используете Zend_Loader или аналогичный), вы можете использовать их вместо или в дополнение к View Helpers.