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

Здравствуйте. В своих проектах 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 (в БД)?
  • Вопрос задан
  • 388 просмотров
Решения вопроса 2
Nipheris
@Nipheris Куратор тега C#
Плюс в том, что структуру и интерфейс модели в больших проектах не хочется делать зависимым от вьюхи в какой бы ни было степени. Вот смотрите, у вас например есть атрибут Display или StringLength - зачастую такие вещи излишни в бизнес-модели. С этой моделью, возможно, будет работать код, вообще не имеющий ничего общего с выводом данных пользователю, например какой-нибудь фоновый бот или сборщик статистики. Или, что чаще встречается, с этой же моделью будет работать совершенно другое представление - например одна вьюха у вас "для всех", т.е. для клиентов, к примеру, интернет-магазина, а другая - для работников, которые обслуживают заказы. И у них те же данные о клиентах и заказах будут выводиться совершенно иначе.
Поэтому как правило удобнее иметь промежуточный слой в виде ViewModel, которая "приближает" данные общей модели к конкретному представлению. Я, например, часто делаю именно во ViewModel различные вычисляемые свойства, которые нужно вывести куда-нибудь, да хоть в таблицу. Т.е. в бизнес-модели у меня расход топлива на километр, и пройденный путь, а во ViewModel помимо этого еще и общий расход топлива на текущий момент времени (который, разумеется, рассчитывается на лету).
Ответ написан
SergeyRodyushkin
@SergeyRodyushkin
.NET Developer
Лично я сторонник такого разделения в силу практики Separation Of Concerns.
Я даже разделяю модель, модель представления и модель запроса (данные, пришедшие от пользователя).
Я люблю, когда объекты домена представляют собой POCO-классы, как правило, неизменяемые — с readonly-полями и валидацией всего в конструкторе. Для получения данных от пользователя я использую отдельные классы с атрибутами валидации, автосвойствами и автоматическим связыванием. Если все хорошо, я просто делаю маппинг в доменный объект и сохранение.
Модель представления нужна, если она комбинирует несколько доменных объектов, содержит данные, нужные только представлению, и так далее. В простых случаях возможно передавать во View сам доменный объект.
Вышесказанное имеет смысл при разработке серьезных приложений. Для простых сайтов на коленке лучше разделение не использовать, или использовать его только там, где это действительно нужно. Минусы заключаются, собственно, в дополнительном количестве кода, который приходится писать и поддерживать. Плюсы — в четком разграничении ответственности и дисциплине.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
Splo1ter
@Splo1ter
.NET Developer (9 years+)
Можно и нужно, т.к. в противном случае получается несоблюдение принципа DRY, в больших проектах иметь тонну моделей и поддерживать все их в актуальном состоянии будет адом.
Ответ написан
Комментировать
@CrazyHorse
А еще можно почитать на тему DDD
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы