Терминология ASP.NET MVC сбивает меня с толку - почему «ViewModel»?

Question

Я новичок в ASP.NET MVC, но ранее использовал много платформ Model-View-Controller.

I недавно натолкнулся на соглашение о сборе фрагментов данных, необходимых вашему конкретному представлению (в действительности, оно назначено ViewData ) в новый класс с именем (NameOfView) ViewModel .

Сбор этих данных так, чтобы они ассоциировались с функциями, предоставляемыми взаимодействием View / Controller, показался мне вспомогательной структурой или даже механизмом закрытия (в смысле «инкапсулирует коллекцию переменных»).

Так почему же он называется ViewModel, учитывая, что это не View или Model?

Кто-нибудь еще находит имя запутанным?

РЕДАКТИРОВАТЬ : Что плохого в том, чтобы просто поместить свойства в представление, чтобы контроллер мог их заполнять (как в других инфраструктурах MVC)?

Answer 1

В моем чтении на эту тему я натолкнулся на множество аргументов относительно того, почему разработчик хотел или не хотел бы использовать ViewModel .Некоторые даже утверждают, что ViewModel никогда не должен предоставлять ничего, кроме строк .На данный момент я не настолько экстремален в своем мышлении.Однако я согласен с тем, что не очень хорошая идея выставлять доменные / базовые объекты на вид.После некоторого опыта из первых рук это чувствует себя более чистым, чтобы удалить эту зависимость.

Хотя я не согласен со всем ниже, Даниэль Рут делает довольно хорошим примером для ViewModel :

Большинство примеров MVCпоказывать напрямую, используя класс модели, такой как класс LINQ-to-SQL или Entity Framework.Проводка Visual Studio для MVC даже вводит вас в эту концепцию благодаря генерации кода по умолчанию «Добавить представление», которая позволяет быстро создавать представления на основе одного класса модели.Однако в реальных приложениях для построения страницы часто требуется нечто большее, чем просто данные одной таблицы.Некоторые примеры решают эту проблему, вставляя вторичные данные в ViewData, но лучший способ сделать это - создать класс «свертки», содержащий свойства для всего , которое понадобится вашему представлению.Это дает дополнительные преимущества более строгой типизации, поддержки intellisense, возможности тестирования и точного определения того, что нужно представлению.

Джефф Хэндли дает хорошее описание ViewModel шаблон , который он утверждает, может использоваться вместе с MVC.

Редактировать Недавно я привел свое мышление в соответствие с Джимми Богардом относительно моделей представлений.После изрядного труда с каждой реализацией я попробовал , имея одну модель представления на представление, создав более чистый опыт разработки.

Answer 2

Модель представляет собой независимое от представления представление данных.Модель view - это представление данных для конкретного вида: это модель , как это может показаться из данной view точки.

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

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

Относительно свойств в представлении по сравнению с пакетом свойств или пользовательским объектом ... Я уверен, что у кого-то есть сильные чувства по этому поводу, но лично я не вижубольшая разница.Вы создаете представление модели для конкретного вида и передаете его как-то ;точный механизм не кажется таким уж важным.

Answer 3

На самом деле это не ответ, но я настоятельно рекомендую вам посмотреть видео MVC2 Basics Скотта Хансельмана. Это все объясняет, и хотя я уже делал ASP.NET MVC до того, как мне многое объяснили.

Это здесь: http://channel9.msdn.com/Blogs/matthijs/ASPNET-MVC-2-Basics-Introduction-by-Scott-Hanselman

Answer 4

Re: почему контроллер не может заполнять свойства в представлении?

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

Я просмотрел сообщения по выбору правильного типа объекта модели здесь: Помещение M в MVC Часть I , Часть II , Часть III .

И да, термин "ViewModel" сейчас в моде, но в духе, который имели в виду первоначальные приверженцы MVC.

Answer 5

Это называется так, потому что это "Модель, созданная для просмотра". Я понимаю, почему выбор термина немного сбивает с толку.

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