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