Значение модели в MVC

Question

Почему МОДЕЛЬ в ASP.NET MVC иногда используется как часть приложения, которое ведет переговоры с базой данных, например here, а иногда как бизнес-объект, который «путешествует» по приложениям, поставляющим данные, такие как here?

Answer 1

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

Мартин Фаулер рассказывает об эволюции MVC здесь. http://martinfowler.com/eaaDev/uiArchs.html

Существует объяснение различий между MVC, MVP и MVVM здесь: http://joel.inpointform.net/software-development/mvvm-vs-mvp-vs-mvc-the-differences-explained/

Мой 10c:

Многие примеры ASP.NET MVC 3, более тесно связаны с шаблоном MVVM, чем MVC. В MVVM ViewModels адаптированы для специфики данных для каждого представления (т. Е. «ViewModels» - это не только модели домена, но и декорированы проблемами уровня представления/представления, такими как правила проверки, подсказки/имена полей, видимость полей и т. Д.).

(Назад к MVC) В небольших проектах с централизованной передачей данных, не требующих многоуровневой интеграции, M может быть такой же простой, как модель ORM (например, .EDMX с некоторыми автогенерированными POCOs) с несколькими правилами. В этом случае MVC можно было бы рассматривать как архитектуру приложения.

Но в больших проектах с использованием MVC оригинальный (Smalltalk) 'M' модели теперь разделен на несколько других слоев, например. объекты домена, сервисные фасады, службы (например, SOA), бизнес и уровни данных и т. д. (здесь здесь M VC - это шаблон уровня представления, а M - это остальная часть вашей системы). Так, например, в таком проекте папка «Модели» вашего проекта MVC может быть просто проксированными ссылками на службы и проксимированными доменами, которые используются для связи с «задним концом» вашей системы или даже с абстракцией этого сообщения (например, см. сервисный агент/служебные фасады, используемые в составном блоке приложений).

Answer 2

На первом снимке вам сообщается, что контроллер строит модель из базы данных, затем модель передается в представление. Второй - тот же, но содержит только простой вид.

Вы можете проверить:

Understand MVC

DTO Pattern + Lazy Loading + Entity Framework + ASP.Net MVC + Auto Mapper

Answer 3

Я думаю о нем, как «бизнес-логики» или «вещи пользователи получают с сайта, не так, как она выглядит» ,

Answer 4

Потому что обе эти вещи являются частью того, что должен выполнять компонент «Модель» в MVC.

Грубо говоря, роли трех компонентов являются:

• Модель реализует всю логику предметной области. Обычно это связано с постоянством (например, с базой данных), но также с бизнес-логикой - в идеальном MVC любая модификация данных вашего домена реализуется как подпрограмма модели.
• Контроллер Контроллер считывает входные данные от пользовательского интерфейса (или независимо от того, что представляет собой ваш открытый интерфейс) и отправляет его в правильную модельную процедуру.
• View преобразует необработанные данные модели во что-то, что пользовательский интерфейс может представлять публичному интерфейсу.

В отличие от многоуровневой архитектуры MVC не различает логику домена и постоянство данных: модель реализует оба.

В действительности, однако, большинство реализаций MVC не на 100% правильны. Общепризнано, что модель сводится к уровню доступа к данным, причем большая часть логики домена происходит в контроллере. На самом деле, иногда неясно, где заканчивается вводная проверка (задание Контролера) и начинается фактическая обработка домена (работа модели). Существует также несколько разногласий по поводу того, как данные передаются от модели к представлению. Контроллер считывает данные модели и передает ее в представление или же модель активно передает свои результаты в представление? Или должен ли View быть активной частью, запрашивая модель для данных?

Answer 5

В шаблоне контроллера модели контроллер является ведущим. Он определяет, какое представление визуализируется, и данные, переданные этому представлению.

В большинстве случаев мы привыкли к архитектуре, которая использует базу данных для сохранения модели. Но это не требование. Модель также может быть сохранена для чего-то еще (например, XML или веб-сервисы).

M также может стоять для просмотра модели. Это означает, что вы не передаете фактическую модель из базы данных в контроллер для просмотра, а используете модель, специально предназначенную для представления.

При использовании Domain Driven Design ваш контроллер действует только для вызова функций в вашем домене. Модель домена содержит фактическую бизнес-логику и предоставляет услуги для доступа к хранилищу сохраняемости (хранилища) и создания новых объектов (фабрик). Затем контроллер должен быть как можно более плоским.

Answer 6

Модели являются самой запутанной частью MVC для понимания.

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

Другие думают с точки зрения моделей-моделей, поэтому они заканчиваются более простыми классами данных.

Лично я со второй связью, поскольку я думаю, что это обеспечивает лучшее разделение проблем.