MVC: мне нужно понять модель

Question

Я уже некоторое время работаю с паттерном MVC, но, честно говоря, я не чувствую, что я действительно понимаю, как работать с «Моделью» и применять ее… Я имею в виду, что можно легко сойти с рук. используя только Controller и View и все будет в порядке.

Я понимаю концепцию модели, но мне просто неудобно применять ее в шаблоне ... Я использую шаблон MVC в .NET, а также Wheels for ColdFusion.

«Модель представляет информацию (данные) приложения и бизнес-правила, используемые для манипулирования данными» - да, я понимаю ... но я просто не совсем понимаю, как применить это. Проще направить вызовы в контроллер и заставить контроллер вызывать базу данных, упорядочивать данные и затем делать их доступными для представления. Я надеюсь, что кто-то понимает, где моя неразбериха ...

Заранее благодарен за помощь!

Answer 1

Посмотри на это так. Когда ваш клиент запрашивает страницу, вот что происходит (массово обрезается):

• Он заканчивается на вашем контроллере

• Контроллер получает необходимые данные от вашей модели

• Затем контроллер передает данные в представление , которое создаст ваш HTML

• Контроллер отправляет HTML обратно клиенту

Итак, клиент -> контроллер -> модель -> контроллер -> вид -> контроллер -> клиент

Так что же такое модель ? Это все, что требуется для получения данных , необходимых для просмотра!

• Это услуги

• Доступ к данным

• Это запросы

• Это отображение объектов

• Критически важна проверка стиля «исключение броска»

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

Для вашего контроллера допустимо делать несколько других вещей, таких как проверка опубликованных данных или некоторая логика if / else, но не запрашивать данные - просто вызывать службы (в вашей области модели) для получения данных требуется для вашего просмотра.

Answer 2

Вот способ, который я объяснил ранее:

• Контроллер: определяет, какие файлы выполняются, включаются и т. Д., И передает пользовательский ввод (если таковой существует)к этим файлам.

• Просмотр: все, что используется для отображения вывода пользователю.

• Модель: все остальное.

Надеюсь, это поможет.

Answer 3

Полагаю, это то, что вы решили назвать различными битами в вашем приложении. Какой бы класс вы не использовали для передачи информации из контроллера в представление, его можно рассматривать как / называемый «модель».

Обычно мы называем Model нашими классами сущностей, и мы называем View Model "вспомогательными" классами, поскольку из-за отсутствия лучшего слова мы используем, когда "чистая" сущность (т. Е. Та, которая будет храниться в базы данных) недостаточно для отображения всей необходимой нам информации в представлении, но все это в основном для именования.

Ваши классы моделей не должны иметь никаких функций; в идеале класс модели будет иметь только свойства. Вы должны видеть классы моделей как контейнеры данных, переносчики информации. Кроме этого они (в основном) "тупые" объекты:

// This would be a model class representing a User
public class User
{
    public int ID { get; set; }
    public string Name { get; set; }
    public string Email { get; set; }
}

Как вы на самом деле передаете информацию (что бы это ни значило в вашем контексте) из вашего контроллера в View и наоборот? Ну, тогда это твоя модель. :)

Answer 4

Модель содержит бизнес-логику (т. Е. Существенные алгоритмы) и постоянное взаимодействие - обычно с базой данных. Контроллер - это MVC framework : Wheels, Struts, .NET MVC. В представлении отображаются данные, которые контроллер получает из модели.

Основная идея MVC заключается в том, что представление и модель не должны знать о контроллере, т. Е. Нет связи. На практике, по крайней мере, существует некоторая связь, но когда она хорошо сделана, она должна быть минимальной, так что она позволяет менять контроллер с минимальными усилиями.

То, что должно происходить, - это запрос, поступающий на контроллер, обычно front controller , где должен быть какой-то написанный вами код, который либо расширяет некоторый объект контроллера, либо следует некоторому соглашению об именах. Этот клейкий код отвечает за вызов методов на правильном уровне службы объекте (ах), упаковку этих данных в некоторый тип помощника - обычно объекта Event - и отправку их в правильное представление. Затем представление распаковывает данные из объекта Event и отображает соответственно.

И если все сделано правильно, это приводит к доменной модели (модель с расширением .k.a.), которая может быть проверена модулем. Причиной этого является то, что вы отдалили алгоритмы от какой-либо структуры или просмотра зависимостей. Так что вы можете проверить их самостоятельно.

Answer 5

model: word, sentence, paragraph
controller: for (word in sentence), blah blah... return paragraph
view: <div>paragraph.text</div>

Идея состоит в том, чтобы разделить проблемы.Почему бы просто не видеть логику контроллера?Модель представляет бизнес-объекты, контроллер управляет этими объектами для выполнения какой-либо задачи, а представление представляет результат.Таким образом, вы можете поменять весь вид на другой, и вам не нужно переписывать все приложение.Вы также можете заставить людей работать на разных уровнях (модель, контроллер, представление), не оказывая существенного влияния на другие уровни.

Объединяя контроллер и модель, вы делаете свой код менее обслуживаемым и расширяемым.По сути, вы не выполняете объектно-ориентированное программирование, поскольку вы не представляете вещи в своей базе данных как объекты, вы просто извлекаете данные и отправляете их в представление.

Answer 6

Модель - это кодовое представление ваших базовых объектов. Несмотря на то, что некоторые модели с меньшим объемом данных могут не подходить для модели MVC, я уверен, что вы всегда найдете подходящее применение.

Давайте возьмем надуманный (но реалистичный) пример полезности модели:

Скажи, что я делаю блог. В моем блоге есть объекты Post. Теперь сообщения используются внутри и вокруг сайта и добавляются многими пользователями в системе. Наша система была закодирована для того, чтобы люди могли вводить HTML в свои посты, но теперь люди начинают добавлять вставленный текст. В этом тексте в качестве символа новой строки используется "\ n".

С моделью это относительно простое исправление. Мы просто делаем геттер, который переопределяет postText:

public function get postText() {
    return this.postText.replace("\n", "<br />");
}

Неожиданно мы можем повлиять на поведение всего сайта с помощью нескольких строк простого кода. Без реализации модели нам нужно было бы найти и добавить аналогичные функциональные возможности везде, где используется postText.

Модель в MVC полностью основана на инкапсуляции и гибкости кодовой базы, которая развивается с течением времени. Чем больше вы работаете с ним и думаете об этом таким образом, тем больше вы обнаруживаете другие случаи, которые в противном случае были бы кошмаром.

- РЕДАКТИРОВАТЬ (вы добавили к своему вопросу выше):

Давайте возьмем этот же пример и используем ваш контроллер для вызова базы данных. У нас есть 9 классов Controller для различных страниц / систем, которые используют объекты Post. Решено, что наша таблица Post должна теперь иметь delete_fl. Мы больше не хотим загружать сообщения с delete_fl = 1.

При правильной реализации нашей модели Post, мы просто редактируем метод loadPosts(), вместо того, чтобы отыскивать все случаи на сайте.

Важным пониманием является то, что в любой крупной системе Модель представляет собой скорее набор файлов, чем отдельный монолит. Обычно у вас будет файл модели для каждой из ваших таблиц базы данных. Пользователь, почта и т. Д.