Что конкретно относится к модели, представлению и контроллеру?

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

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

Маршрутизатор / Диспетчер / Передний Контроллер:

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

Модель:

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

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

    • контроллер"Вопрос" будет спрашивать модель : "пожалуйста, дайте данные для вопроса 123."
    • модель затем переведет это в "SELECT * FROM Questions WHERE Id = 123;" и перенесет его в базу данных
    • база данных вернет в модель запись "Вопрос" .
      • Модель возьмет запись и переведет ее в вопрос. объект данных
    • Затем модель задает то же самое "SELECT * FROM Answers WHERE QuestionID = 123;" и создает массив объектов ответа из результирующего набора, а затем добавляет его к переменной-члену answers объекта Question.
  • Модель вернет объект вопроса контроллеру"Вопрос" .

Контроллер:

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

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

    • обеспечение входа пользователя в систему.
    • определение QuestionId из URL-адреса.
    • определение того, какой вид использовать.
    • отправка HTTP-кодов и перенаправление, если это необходимо.
    • запрашивает данные у модели и сохраняет необходимые данные в переменных-членах.

Вид:

    По большому счету, представление-это самая простая часть приложения. В основном он состоит из HTML-шаблонов в базовом приложении. Эти шаблоны будут иметь заполнители для вставки данных в шаблон от члена контроллера переменные:

Например 

<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() выше взял бы массив ответов, взятых из контроллера , и перебирал бы их, вызывая что-то вроде include $markupPath . "/formatAnswer.inc", который был бы небольшим шаблоном только контейнера ответов.

Вопросы:

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

2 ответа:

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

Понимание MVC: что такое понятие "толстый" на моделях," тощий " на контроллерах?

2

По существу, у вас есть все в нужном месте.

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

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

0