Этот код безумен?

Question

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

Прежде всего, я пошлю 100 очков брауни, 2 моих питомца и коробка с шоколадом кто может объяснить мне, что это происходит с этим кодом.

Он использует модульную архитектуру. Имя модуля frontmodule. Модуль имеет MVC. И модуль имеет собственный внутренний library.

  /modules/    
      /frontmodule/
          /models/
          /views/
          /controllers/        -- the /module controller is here (undestandable)
          /library/            
             /Controller/      -- the /module/library controller is here (why?!)
                /Action/

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

Теперь идет интересная часть .... в дополнение к каждому модулю, имеющему свою собственную внутреннюю библиотеку, есть также общая библиотека, общая для всех модулей (см. Ниже на том же уровне папок, что и * 1022). *) и эта общая библиотека также имеет свои собственные контроллеры и действия (так же, как у каждой внутренней библиотеки есть свои собственные контроллеры и действия)

  /modules
  /library/
      /Common/
          /Controller/         -- the /common/library controller is here (why?!)
              /Action/
                  /Helper/
              /Plugin/

Итак, у нас есть 3 контроллера:

• модуль контроллера
• контроллер внутренней библиотеки модуля
• контроллер общей библиотеки

Теперь вот безумная часть, которую я считаю чрезмерно усложняющей жизнь

Он говорит: модуль контроллера расширяет родительский контроллер библиотеки модуля который также расширяет общую библиотеку контроллер.

class IndexController 
       extends Frontoffice_Library_Controller_Action_Abstract { ... }

abstract class Frontoffice_Library_Controller_Action_Abstract 
       extends Custom_Controller_Action_Abstract { ... }

Итак, я думаю:

• модуль контроллера = IndexController
• контроллер внутренней библиотеки модуля = Frontoffice_Library_Controller_Action_Abstract
• контроллер общей библиотеки = Custom_Controller_Action_Abstract

, где module controller расширяется module internal library's controller

и module internal library's controller расширяются common library's controller

Кто-нибудь видел что-нибудь подобное раньше? Я предполагаю, что этот код будет нелегко поддерживать, но, возможно, те, кто более опытен в Zend, могут сказать мне, чего этот парень пытается достичь. Структура приложения немного слишком грязная. Я думаю, что он злоупотребляет MVC вместо того, чтобы использовать его для упрощения приложения и его удобства обслуживания.

Answer 1

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

Zend Framework MVC чрезвычайно гибок ... даже до такой степени, что многие обвиняют его в том, что он закончилсяИнженерный или раздутый сам.Это субъективно.

Конечно, вы, вероятно, не захотите использовать Zend Framework для простой контактной формы;однако ничто не мешает вам использовать только Zend_Mail и Zend_Form без Zend MVC / Application.Учитывая гибкость, в настоящее время не существует единой методологии, которая считается лучшей с точки зрения организации приложения в модули.Эту задачу лучше всего оставить на усмотрение разработчика.

Это подводит нас к учебнику под рукой.Автор учебника предложил стратегию для повторного использования.Это хорошая вещь;однако в его подходе есть некоторые недостатки.

1. Библиотека на модуль. Это не обязательно плохо;однако в большинстве случаев это не обязательно.Давайте рассмотрим, какие у нас есть варианты на случай, если такая структура нужна по какой-то причине .

   a .Создайте общую библиотеку (вы, скорее всего, уже делаете это) пространства имен (псевдо, если <5.3, или фактические пространства имен, если> = 5.3).

   b .Используйте встроенный «Resource Autoloader» http://framework.zend.com/manual/en/zend.loader.autoloader-resource.html

   ПРИМЕЧАНИЕ. Я лично не слишком часто использовал автозагрузку ресурсов.Однажды, когда я его использовал, я обнаружил, что мог просто перенести эти предметы в свою библиотеку.Это, как говорится, есть польза для этого.Похоже, что светит, когда вы ожидаете смешивать и сопоставлять модули в рамках проектов или для распространения.ИМХО ZF2 решит эту проблему менее хакерским способом.

2. Базовые контроллеры для повторного использования .Опять же, повторное использование это здорово;тем не менее, Zend Framework предоставляет лучшие альтернативы подклассификации (наследования) контроллеров.Во-первых, вот несколько причин НЕ использовать наследование контроллера:

   a .Хранение вещей СУХОЙ побеждено, когда у вас есть несколько модулей, которые достаточно различаются, чтобы иметь базовый класс для каждого модуля, но функциональность копируется / вставляется в базовый класс контроллера каждого модуля.

   b .Становится трудно управлять унаследованными свойствами, поскольку становится труднее представить, какие унаследованные функции используются каждым контроллером / действием

   c .Благодаря PHP, разрешающему наследование только одного класса, вы теряете здесь один шанс наследования - используйте его только в том случае, если не осталось других вариантов

   Альтернативы :

   а .Плагины Front-Controller Используйте их, когда функциональность / логика должна выполняться при каждом запросе независимо от модуля / контроллера / действия

   b .Помощники действий Как упомянул руководитель проекта ZF: «Это встроенный механизм в Zend Framework, позволяющий расширять ваши контроллеры действий таким образом, чтобы использовать композицию вместо наследования».В контроллере нет ничего, что вы можете сделать с помощью помощника действий.Используйте их, когда функциональность должна происходить для каждого контроллера и / или для каждого действия.

Итак, был ли пример в руководстве слишком перегружен? Не обязательно ;тем не менее, он, безусловно, является кандидатом на неправильно спроектированный , поскольку он относится к передовым методам и положениям Zend Framework.

Мне нужно на минутку отвлечься и обсудить условия перегружен и раздут на мгновение

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

Статья в Википедии - http://en.wikipedia.org/wiki/Overengineering частично гласит: «... когда продукт более устойчив или сложен, чем необходимо для его применения ...».

Поэтому, когда вы называете что-то чрезмерно спроектированным / раздутым, нужно быть осторожным, чтобы квалифицировать приложение context или под рукой.Общие заявления должны быть взяты с крошкой соли и в большинстве случаев, вообще не приняты.Это все равно что сказать что-то вроде: «Я бы никогда не использовал« Циркулярную пилу »для деревообработки, поскольку в ней слишком много функций, и эти функции меня смущают».Несомненно, этот инструмент может быть чрезмерным для небольших домашних / побочных проектов;однако, поскольку он очень гибкий, вы будете рады, что у вас есть этот инструмент, когда вы окажетесь в ситуациях, в которых вы никогда не думали, что окажетесь.

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

Дополнительная информация :

1. Если вы хотитепереключение раскладок на основе модуля / контроллера / действия, вы можете написать плагин Front-Controller.Просто вызовите «Zend_Layout :: startMvc» и передайте ему имя макета и путь.

2. Переключение реального сценария просмотра на основе заголовка Accept (или параметра URL или X-HTTP-METHOD-OVERRIDE заголовок) можно сделать с помощью помощника переключения контекста (встроенного в Zend Framework) - http://framework.zend.com/manual/en/zend.controller.actionhelpers.html

3. Не стесняйтесь передавать экземпляр модели помощнику действий.Вы также можете настроить помощников действий с помощью конфигурации из начальной загрузки.Таким образом, нет необходимости хранить вещи в глобальном реестре, который является просто прославленной глобальной переменной.Это скрытая зависимость, которая вам не нужна.Для лучшего повторного использования вы можете создать свои собственные пользовательские подключаемые модули, расширив Zend_Application_Resource_ResourceAbstract - http://framework.zend.com/manual/en/zend.application.core-functionality.html#zend.application.core-functionality.resource-resourceabstract

Answer 2

Это безумие. Вы делаете веб-страницы, верно? Это не сложно Я бы сказал, что материал, который вы разместили, - это само определение техники:

http://en.wikipedia.org/wiki/Overengineering

Answer 3

Совсем не безумие. Возможно, плохо или чрезмерно спроектирован, но это может быть полезной настройкой.

Это просто два «дополнительных» уровня наследования, которые в некоторых случаях могут иметь смысл.

• свойства или методы, которые должны быть доступны на каждом контроллере в системе, указываются в «общем контроллере библиотеки».
• свойства или методы, которые должны быть доступны в каждом контроллере в конкретный модуль перейти в «модуль контроллер внутренней библиотеки "-
• свойства или методы, требуемые один, конкретный контроллер, жить в этот конкретный контролер.

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

Answer 4

Таким образом, вы можете применить логику к:

a) конкретному контроллеру

b) ко всем контроллерам в одном модуле

c) ко всем прикладным контроллерам