Я изучал парадигму Model-View-Controller ("MVC"), но я совершенно сбит с толку, поскольку некоторые учебные пособия противоречат другим учебным пособиям.
Мое текущее понимание процесса выглядит примерно так:
Маршрутизатор/Диспетчер/Фронт-контроллер:
- Хотя это и не указано в названии "MVC", Маршрутизатор по-прежнему является очень важной частью. Именно здесь запросы транслируются с необработанных URL-адресов на определенный контроллер. Например, перенаправить запрос для www.StackUnderflow.com/question/123 на контроллер "Вопрос" приложения.
Модель:
Здесь исходные данные собираются из некоторого источника хранения, такого как база данных или файл XML. Модель служит в качестве уровня абстракции, переводит запрос контроллера для конкретных данных (например, в запрос SQL) и переводит результаты запроса в стандартный формат, такой как объект данных.
Например, в сценарии /browse/all, указанном выше:
- Контролер "Вопрос" задаст модели "Пожалуйста, предоставьте данные для вопроса 123."
- Модель затем перевела бы это в "ВЫБРАТЬ * ИЗ ВОПРОСОВ, ГДЕ Id = 123;" и положить его в базу данных
- База данных вернет запись "Вопрос" в модель.
- Модель берет запись и переводит ее в объект данных Вопроса
- Затем модель спрашивает, делает ли это то же самое: "ВЫБЕРИТЕ * ОТ ОТВЕТОВ ГДЕ QuestionID = 123;" и создает массив объектов Answer из результирующего набора и добавляет его к переменной-члену объекта Question.
- Модель возвращает объект "Вопрос" контроллеру "Вопрос".
Контроллер:
Это настоящая рабочая лошадка приложения. В дополнение к ретрансляции сообщений туда и обратно в Модель и Представление, Контроллер также отвечает за такие вещи, как Авторизация
и логика приложения/"бизнеса"Редактировать: По каждому ответу бизнес-логика принадлежит Модели.В текущем примере Контроллер будет нести ответственность за:
- Обеспечение входа пользователя в систему.
- Определение QuestionId по URL.
- Определение используемого вида.
- Отправка HTTP-кодов и перенаправление при необходимости.
- Запрашиваемая модель для данных и хранить необходимые данные в переменных-членах.
Вид:
- По большому счету, View является самой простой частью приложения. В основном приложение состоит из шаблонов 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, а другой просто хранит связанные данные для передачи. Это нормально, или некоторые должны быть объединены. Если да, то какие?
