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

Я следую учебнику, который, как мне кажется, написан кем-то, кто не знает, что он делает (уже поймал 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/

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

Теперь появляется интересная часть.... помимо каждого модуля, имеющего собственную внутреннюю библиотеку, есть также общая библиотека, доступная для всех модулей (см. ниже на том же уровне папки, что и /modules), и что Common Library также имеет свои собственные контроллеры и действия (так же, как каждая внутренняя библиотека имеет свои собственные контроллеры и действия)

  /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 controller

и module internal library controller продолжается common library controller

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

Ответ 1

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

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

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

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

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

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

б. Используйте собственный "Автозагрузчик ресурсов", http://framework.zend.com/manual/en/zend.loader.autoloader-resource.html

ПРИМЕЧАНИЕ. Я лично не использовал автозагрузку ресурсов. Однажды, когда я его использовал, я обнаружил, что могу просто перенести эти элементы в свою библиотеку. При этом для этого есть использование. Кажется, он блистает, когда вы планируете смешивать и сопоставлять модули по проектам или для распространения. ZF2 обратится к этому менее опасным способом IMHO.
Базовые контроллеры для повторного использования. Опять же, повторное использование велико; однако Zend Framework предоставляет лучшие альтернативы контроллерам подкласса (наследования). Во-первых, здесь есть некоторые причины НЕ использовать наследование контроллера:

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

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

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

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

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

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

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

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

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

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

Таким образом, когда вы ссылаетесь на что-то, как Over-developed/bloated, нужно быть осторожным, чтобы квалифицировать контекст или приложениепод рукой. Заявки на одеяло следует брать с солью и в большинстве случаев не принимать вообще. Это похоже на высказывание чего-то типа "Я бы никогда не использовал" Циркулярную пилу "для деревообработки, так как у нее слишком много функций, и эти функции меня путают". Конечно, этот инструмент может быть слишком убит для небольших домашних проектов; однако, поскольку это супер гибкий, вы будете счастливы, что у вас есть этот инструмент, когда вы окажетесь в ситуациях, когда вы никогда не думали, что найдете себя.

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

Дополнительные сведения:

Если вы хотите переключать макеты на основе модуля/контроллера/действия, вы можете написать плагин Front-Controller. Просто позвоните "Zend_Layout:: startMvc" и передайте ему имя макета и путь.
Переключение фактического представления script на основе заголовка Accept (или URL-адреса или заголовка X-HTTP-METHOD-OVERRIDE) может быть выполнено с помощью помощника действий контекстного переключателя (присущего Zend Framework) - http://framework.zend.com/manual/en/zend.controller.actionhelpers.html
Не стесняйтесь передавать экземпляр модели в помощник действия. Вы также можете настроить свои помощники действий с настройкой из бутстрапа. Таким образом, нет необходимости хранить вещи в глобальном реестре, который является просто прославленной глобальной переменной. Это скрытая зависимость, которая вам не нужна. Для лучшего повторного использования вы можете создавать свои собственные собственные подключаемые ресурсы, расширяя Zend_Application_Resource_ResourceAbstract - http://framework.zend.com/manual/en/zend.application.core-functionality.html#zend.application.core-functionality.resource-resourceabstract

Ответ 2

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

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

Ответ 3

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

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

свойства или методы, которые должны быть доступны на каждом контроллере в системе, входят в "общий библиотечный контроллер".
свойства или методы, которые должны быть доступный в каждом контроллере в конкретный модуль входит в модуль внутренний контроллер библиотеки "-
свойства или методы, требуемые одиночный, бетонный контроллер, жить в что конкретный контроллер.

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

Ответ 4

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

a) конкретный контроллер

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

c) все контроллеры приложений