Можно ли использовать Model для взаимодействия с View вместо ViewModel?

Question

[Николай Мохов]

Здравствуйте. В своих проектах ASP.NET MVC 5 при создании модели я сразу указываю все необходимые мне атрибуты, например

[Required]
        [StringLength(maximumLength: 120, ErrorMessage = "Значение {0} должно содержать символов не менее {2}, и не более {1}.", MinimumLength = 10)]
        [Display(Name = "Название")]
        [DataType(DataType.Text)]
        public string Name { get; set; }

и использую эту модель для генерации View.
Но очень часто встречаю примеры когда разделяются Model и ViewModel. Так вот хотел спросить какие плюсы и минусы несет данный подход, кроме как определения свойств(полей) в ViewModel которые не используется в Model (в БД)?

Answer 1

[Станислав Макаров]

Плюс в том, что структуру и интерфейс модели в больших проектах не хочется делать зависимым от вьюхи в какой бы ни было степени. Вот смотрите, у вас например есть атрибут Display или StringLength - зачастую такие вещи излишни в бизнес-модели. С этой моделью, возможно, будет работать код, вообще не имеющий ничего общего с выводом данных пользователю, например какой-нибудь фоновый бот или сборщик статистики. Или, что чаще встречается, с этой же моделью будет работать совершенно другое представление - например одна вьюха у вас "для всех", т.е. для клиентов, к примеру, интернет-магазина, а другая - для работников, которые обслуживают заказы. И у них те же данные о клиентах и заказах будут выводиться совершенно иначе.
Поэтому как правило удобнее иметь промежуточный слой в виде ViewModel, которая "приближает" данные общей модели к конкретному представлению. Я, например, часто делаю именно во ViewModel различные вычисляемые свойства, которые нужно вывести куда-нибудь, да хоть в таблицу. Т.е. в бизнес-модели у меня расход топлива на километр, и пройденный путь, а во ViewModel помимо этого еще и общий расход топлива на текущий момент времени (который, разумеется, рассчитывается на лету).

Comments

[Николай Мохов]

спасибо за примеры, стало понятнее. Осталось разобраться AutoMapper чтоб проще было писать

[Razaz]

Kolay_Net: Я отказался от автомапера и перенес логику маппинга в конструктор ViewModel. Таким образом, если понадобятся справочники - их легко добавлять и интерфейс взаимодействия выглядит целостным. Есть еще фокус - можно внутри ViewModel делать InputModel, что бы разграничить данные, которые необходимо получить назад.

Answer 2

[Сергей Родюшкин]

Лично я сторонник такого разделения в силу практики Separation Of Concerns.
Я даже разделяю модель, модель представления и модель запроса (данные, пришедшие от пользователя).
Я люблю, когда объекты домена представляют собой POCO-классы, как правило, неизменяемые — с readonly-полями и валидацией всего в конструкторе. Для получения данных от пользователя я использую отдельные классы с атрибутами валидации, автосвойствами и автоматическим связыванием. Если все хорошо, я просто делаю маппинг в доменный объект и сохранение.
Модель представления нужна, если она комбинирует несколько доменных объектов, содержит данные, нужные только представлению, и так далее. В простых случаях возможно передавать во View сам доменный объект.
Вышесказанное имеет смысл при разработке серьезных приложений. Для простых сайтов на коленке лучше разделение не использовать, или использовать его только там, где это действительно нужно. Минусы заключаются, собственно, в дополнительном количестве кода, который приходится писать и поддерживать. Плюсы — в четком разграничении ответственности и дисциплине.

Comments

[Артур Нуруллин]

У вас много моделей в проекте ?

[Сергей Родюшкин]

Артур Нуруллин: Много — понятие относительное :) В тех проектах, над которыми я работаю, число сущностей измеряется десятками. View-моделей обычно побольше.

[Артур Нуруллин]

Сергей Родюшкин: вас не за*вает поддерживать их в актуальном состоянии по сравнению с POCO ?

[Сергей Родюшкин]

Артур Нуруллин: Сущности у нас меняются редко, поэтому нет. При добавлении новых — да, нужно написать еще код, хотя, учитывая, что это обычно классы с автосвойствами и атрибутами валидации, это быстро. С маппингом туда-обратно справляется AutoMapper. POCO, согласитесь, с дополнительной атрибутикой уже не совсем POCO.

Answer 3

[Артур Нуруллин]

Можно и нужно, т.к. в противном случае получается несоблюдение принципа DRY, в больших проектах иметь тонну моделей и поддерживать все их в актуальном состоянии будет адом.

Answer 4

[CrazyHorse]

А еще можно почитать на тему DDD