Что конкретно принадлежит в модели, представлении и контроллере? - PullRequest
10 голосов
/ 23 августа 2010

Я изучал парадигму Model-View-Controller ("MVC"), но я совершенно сбит с толку, поскольку некоторые учебные пособия противоречат другим учебным пособиям.

Мое текущее понимание процесса выглядит примерно так:

Маршрутизатор / Диспетчер / Фронт-контроллер:

  • Хотя в названии "MVC" нет конкретной ссылки, Маршрутизатор по-прежнему является очень важной частью. Именно здесь запросы транслируются с необработанных URL-адресов на определенный контроллер. Например, маршрутизация запроса на www.StackUnderflow.com/question/123 к «Вопросному» контроллеру приложения.

Модель:

  • Здесь исходные данные собираются из некоторого источника хранения, такого как база данных или файл XML. Модель служит в качестве уровня абстракции, транслируя запрос Controller для конкретных данных (например, в SQL-запрос) и переводя результаты запроса в стандартный формат, такой как объект данных.

  • Например, в указанном выше сценарии / browse / all:

    • Контроллер «Вопрос» задаст Модель «Пожалуйста, предоставьте данные для вопроса 123.»
    • Затем модель перевела бы это в «ВЫБРАТЬ * ИЗ ВОПРОСОВ, ГДЕ Id = 123;» и положить его в базу данных
    • База данных будет возвращать «Вопрос» запись в Модель.
    • Модель берет запись и переводит ее в объект данных
    • Затем модель спрашивает, делает ли то же самое "ВЫБРАТЬ * ОТ ОТВЕТОВ ГДЕ QuestionID = 123;" и создает массив объектов ответа из набора результатов и добавляет его в переменную-член объекта ответа Вопрос.
    • Модель будет возвращать объект Вопрос контроллеру «Вопрос» .

Контроллер:

  • Это настоящая рабочая лошадка приложения. В дополнение к ретрансляции сообщений туда и обратно на Model и View , контроллер также отвечает за такие вещи, как авторизация и бизнес-приложения / " "логика Редактировать: согласно ответу, бизнес-логика принадлежит модели.

  • В текущем примере Контроллер будет нести ответственность за:

    • Обеспечение входа пользователя в систему.
    • Определение идентификатора вопроса по URL.
    • Определение используемого вида.
    • Отправка HTTP-кодов и перенаправление при необходимости.
    • Запрос Model о данных и сохранение необходимых данных в переменных-членах.

Вид:

  • По большому счету, View является самой простой частью приложения. В основном приложение состоит из шаблонов HTML. Эти шаблоны будут иметь заполнители для вставки данных в шаблон из переменных-членов контроллера:
* 1 094 *, например
<html>

  <head>
    <title>
      <?php $question->getTitle() ?>
    </title>
  </head>

  <body>
    <h1> <?php $question->getQuestionText(); ?> </h1>
    <h2> Answers: </h2>
    <div class="answerList"> 
      <?php formatAnswerList($question->getAnswers()); ?> 
    </div>
  </body>

</html>
  • Представление также будет содержать методы для форматирования данных для доставки пользователю. Например, метод formatAnswerList(), описанный выше, будет принимать массив ответов, взятых из Controller , и проходить по ним, вызывая что-то вроде include $markupPath . "/formatAnswer.inc", что будет небольшим шаблоном из контейнера ответов.

Вопросы:

  • Является ли этот взгляд на MVC принципиально точным?
  • Если нет, пожалуйста, внимательно объясните, какие компоненты находятся не на своем месте, куда они должны на самом деле идти, и как они должны должным образом взаимодействовать с другими компонентами (если вообще).
  • Сколько классов используется для описания этого? В моем примере есть четыре объекта - каждый для трех компонентов MVC, а другой просто хранит связанные данные для передачи. Это нормально, или некоторые должны быть объединены. Если да, то какие?

Ответы [ 2 ]

2 голосов
/ 23 августа 2010

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

Понимание MVC: что такое понятие «жир» на моделях, «тощий» на контроллерах?

0 голосов
/ 23 августа 2010

По сути у вас все в нужном месте.

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

В некоторых случаях я видел, что ViewModel упускается из виду, и Модель передается в View - это смущало меня, когда я впервые смотрел учебники, и мне не нравится пропускать ViewModel, я думаю, что это смущает вещи.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...