Как отделить представление от контроллера?

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

В своих приложениях я инициализирую представление в контроллере (псевдокод), как показано ниже.

var controller = (function(){

   return {
      init: function()
      {
          this.view = new View("template");
          this.view.render();
      }
   }

})();

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

может ли кто-нибудь дать мне идею или пример кода или концепции?


person Moon    schedule 11.01.2012    source источник


Ответы (1)


Прежде всего, немного о ролях Ms, Vs и Cs в шаблоне MVC:

Три части:

Model-Просмотр-Контроллер:

Мы будем называть неизменную сущность приложения/домена моделью (в единственном числе). С точки зрения объектно-ориентированного подхода, это будет набор классов, которые моделируют и поддерживают основную проблему и, следовательно, будут иметь тенденцию быть стабильными и такими же долгоживущими, как и сама проблема.
Сколько должна модель ( классы) знаете о связи с внешним миром? Ничего, абсолютно ничего.

Модель-View-Контроллер:

Для данной ситуации в данной версии будет один или несколько интерфейсов с моделью, которые мы будем называть представлениями (во множественном числе). В объектно-ориентированных терминах они будут состоять из наборов классов, которые дают нам «окна» (очень часто настоящие окна).

Модель-Вид-Controller:

Контроллер — это объект, который позволяет вам манипулировать представлением. Немного упрощая, контроллер обрабатывает ввод, а представление обрабатывает вывод. Контроллеры лучше всех разбираются в платформах и операционных системах. Представления довольно независимы от того, происходит ли их событие из Microsoft Windows, X Windows или чего-то еще.


Вот что ваш коллега пытается вам сказать:

На приведенном ниже рисунке показан поток операций (приблизительный), относящийся к фреймворку Zend, который представляет собой фреймворк MVC для PHP.

Нажмите здесь для увеличения изображения.
Вызовы Zend Framework


Обратите внимание на Dispatcher (третий от последнего) на приведенной выше диаграмме.
Давайте рассмотрим только следующее для вашего случая:

  • Front.php: как вы видите.
  • Диспетчер: посредник, упомянутый вашим коллегой.
  • MyController : как ваш контроллер.

Вам нужно будет сделать следующее:
если представление должно инициировать событие, оно не будет обрабатывать это событие само по себе. Он отправит событие в Диспетчер вместе с параметрами (если они есть) для события.

Теперь Диспетчер

  • Ищите контроллер, способный обрабатывать такое событие.
  • Создайте контроллер
  • Передайте событие контроллеру вместе с параметрами (если есть).

Теперь контроллер будет:

  • Подготовьтесь к мероприятию.
  • Выполнить событие.
  • Верните набор результатов (если есть) в Dispatcher.

Теперь Диспетчер будет:

  • Верните набор результатов (если есть) обратно в View.

Представление теперь будет:

  • Визуализируйте набор результатов (если есть) и представьте его.

Почему так много нужно сделать?
To keep the roles segregated and clear.

person ThinkingMonkey    schedule 11.01.2012
comment
ThinkingMonkey // Спасибо за подробный ответ. Однако я не вижу представления на диаграмме. См. framework.zend.com/manual/en/, прокрутите вниз до ErrorController. Он также использует представление внутри контроллера. - person Moon; 12.01.2012
comment
@moon Да, на диаграмме нет представления. Вот почему я попросил вас рассматривать front.php как представление. Когда дело доходит до MVC, было много различий в реализации. (см. здесь). Если рассматривать традиционный шаблон, views know their model but the model doesn't know its views, the controllers knows their views but the view doesn't know its controller. То, что вы делаете, не является неправильным или плохой практикой. - person ThinkingMonkey; 12.01.2012
comment
@moon Это просто выбор того, как вы хотите называть представление. Отвечая на ваш вопрос, я просто концентрируюсь на том, как отделить представление от контроллера и использовать посредник для работы с ними. - person ThinkingMonkey; 12.01.2012
comment
// Я ценю ваш ответ, но он все еще не имеет смысла. Как вы знаете, Zend Framework использует реальное представление в своих контроллерах, как и я в своем псевдокоде. Тогда остается вопрос, почему даже Zend Framework использует представление в своем контроллере? это почти тот же вопрос, который у меня есть. - person Moon; 12.01.2012
comment
@moon, как я уже сказал, это для разделения интересов и того, что то, что вы делаете, не является неправильным или плохой практикой.. Посредник — это просто дополнительный модуль в вашем MVC. Ваш коллега, вероятно, предлагает это для: он не хочет, чтобы основные файлы приложения, т. е. Models, View, Controllers, не взаимодействовали напрямую. - person ThinkingMonkey; 12.01.2012
comment
@moon Другими словами: Контроллер не наблюдает за работой представлений и моделей - это не GodClass. Контроллер обеспечивает связь и унифицирует проверку, используя либо прямые вызовы, либо ObserverPattern. from: Cunningham & Cunningham, Inc.: Контроллер представления модели. - person ThinkingMonkey; 12.01.2012
comment
ThinkingMoney // Спасибо за предложение, но мой вопрос все еще остается. - person Moon; 13.01.2012