Является ли этот код безумным?

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/ 

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

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

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

Итак, мы имеют 3 контроллеров:

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

Теперь вот безумным часть, я думаю, что это чрезмерно усложнять жизнь

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

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. Использовать собственный «Автозагрузчик ресурсов» http://framework.zend.com/manual/en/zend.loader.autoloader-resource.html

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

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

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

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

   c. С PHP позволяет наследование только одного класса, Вы уносите свой единственный шанс на наследство здесь - использовать только если нет никаких других вариантов не осталось

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

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

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

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

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

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

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

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

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

Extra Info:

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

2. Переключение фактического скрипта вида, основанный на Accept заголовок (или параметр URL или X-HTTP-Method Непереопределяемый заголовок) может быть сделано с помощником переключение контекста действий (присущего 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

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

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

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

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