Изменить: я обновил этот ответ в своем блоге:
http://www.samwheat.com/post/The-function-of-ViewModels-in-MVC-web-development
Мой ответ немного длинен, но я думаю, что важно сравнить модели представления с другими типами часто используемых моделей, чтобы понять, почему они отличаются и почему они необходимы.
Подводя итог, и прямо ответить на вопрос, который задают:
Вообще говоря, модель представления - это объект, который содержит все свойства и методы, необходимые для визуализации представления. Свойства модели представления часто связаны с объектами данных, такими как клиенты и заказы, и, кроме того, они также содержат свойства, связанные с страницей или самим приложением, такие как имя пользователя, имя приложения и т. Д. Модели представления предоставляют удобный объект для передачи в механизм рендеринга. создать HTML-страницу. Одна из многих причин использования модели представления заключается в том, что модели представления предоставляют способ модульного тестирования определенных задач представления, таких как обработка пользовательского ввода, проверка данных, получение данных для отображения и т. Д.
Вот сравнение моделей Entity (a.ka. DTO's a.ka. models), презентационных моделей и моделей просмотра.
Объекты передачи данных ака «Модель»
Объект передачи данных (DTO) - это класс со свойствами, которые соответствуют схеме таблицы в базе данных. DTO названы по их общему использованию для передачи данных в и из хранилища данных.
Характеристики DTO:
• являются бизнес-объектами - их определение зависит от данных приложения.
• Обычно содержат только свойства - без кода.
• В основном используется для передачи данных в базу данных и из нее.
• Свойства точно или близко совпадают с полями определенной таблицы в хранилище данных.
Таблицы базы данных обычно нормализуются, поэтому DTO обычно также нормализуются. Это делает их ограниченным использованием для представления данных. Однако для некоторых простых структур данных они часто работают достаточно хорошо.
Вот два примера того, как может выглядеть DTO:
public class Customer
{
public int ID { get; set; }
public string CustomerName { get; set; }
}
public class Order
{
public int ID { get; set; }
public int CustomerID { get; set; }
public DateTime OrderDate { get; set; }
public Decimal OrderAmount { get; set; }
}
Презентационные модели
Модель представления - это служебный класс, который используется для отображения данных на экране или в отчете. Модели представления обычно используются для моделирования сложных структур данных, которые состоят из данных из нескольких DTO. Модели представления часто представляют денормализованное представление данных.
Характеристики презентационных моделей:
• являются бизнес-объектами - их определение зависит от данных приложения.
• Содержат в основном свойства. Код обычно ограничен форматированием данных или преобразованием в или из DTO. Модели презентаций не должны содержать бизнес-логики.
• Часто представляют денормализованное представление данных. То есть они часто объединяют свойства нескольких DTO.
• Часто содержат свойства другого базового типа, чем DTO. Например, суммы в долларах могут быть представлены в виде строк, поэтому они могут содержать запятые и символ валюты.
• Часто определяется тем, как они используются, а также характеристиками их объектов. Другими словами, простой DTO, который используется в качестве вспомогательной модели для визуализации сетки, на самом деле также является моделью представления в контексте этой сетки.
Модели представления используются «по мере необходимости» и «где необходимо» (тогда как DTO обычно привязаны к схеме базы данных). Модель представления может использоваться для моделирования данных для всей страницы, сетки на странице или раскрывающегося списка сетки на странице. Модели презентаций часто содержат свойства, которые являются другими моделями презентаций. Модели представления часто создаются для одноразового использования, например, для визуализации конкретной сетки на одной странице.
Пример модели презентации:
public class PresentationOrder
{
public int OrderID { get; set; }
public DateTime OrderDate { get; set; }
public string PrettyDate { get { return OrderDate.ToShortDateString(); } }
public string CustomerName { get; set; }
public Decimal OrderAmount { get; set; }
public string PrettyAmount { get { return string.Format("{0:C}", OrderAmount); } }
}
Посмотреть модели
Модель представления аналогична модели представления в том, что является базовым классом для визуализации представления. Однако это очень отличается от модели представления или DTO в том, как она построена. Модели представлений часто содержат те же свойства, что и модели представления и DTO, и по этой причине их часто путают друг с другом.
Характеристики моделей просмотра:
• Являются ли единственным источником данных, используемых для отображения страницы или экрана. Обычно это означает, что модель представления будет предоставлять все свойства, которые любой элемент управления на странице должен будет правильно отображать. Создание модели представления в качестве единственного источника данных для представления значительно улучшает его возможности и ценность для модульного тестирования.
• являются составными объектами, которые содержат свойства, которые состоят из данных приложения, а также свойств, которые используются кодом приложения. Эта характеристика имеет решающее значение при разработке модели представления для повторного использования и обсуждается в примерах ниже.
• Содержать код приложения. Модели представления обычно содержат методы, которые вызываются во время рендеринга и когда пользователь взаимодействует со страницей. Этот код обычно относится к обработке событий, анимации, видимости элементов управления, стилям и т. Д.
• Содержат код, который вызывает бизнес-сервисы с целью извлечения данных или отправки их на сервер базы данных. Этот код часто ошибочно помещается в контроллер. Вызов бизнес-сервисов из контроллера обычно ограничивает полезность модели представления для модульного тестирования. Чтобы было понятно, сами модели представлений не должны содержать бизнес-логику, а должны вызывать сервисы, которые содержат бизнес-логику.
• Часто содержат свойства, которые являются другими моделями представления для других страниц или экранов.
• написаны «на страницу» или «на экран». Уникальная модель представления обычно пишется для каждой страницы или экрана в приложении.
• Обычно наследуются от базового класса, поскольку большинство страниц и экранов имеют общие свойства.
Посмотреть состав модели
Как указывалось ранее, модели представления являются составными объектами в том смысле, что они объединяют свойства приложения и свойства бизнес-данных в одном объекте. Примеры часто используемых свойств приложения, которые используются в моделях представления:
• Свойства, которые используются для отображения состояния приложения, такие как сообщения об ошибках, имя пользователя, состояние и т. Д.
• Свойства, используемые для форматирования, отображения, стилизации или анимации элементов управления.
• Свойства, используемые для привязки данных, такие как объекты списка и свойства, которые содержат промежуточные данные, введенные пользователем.
Следующие примеры показывают, почему составная природа моделей представлений важна и как мы можем наилучшим образом построить модель представления, которая была бы эффективной и многократно используемой.
Предположим, мы пишем веб-приложение. Одним из требований дизайна приложения является то, что заголовок страницы, имя пользователя и имя приложения должны отображаться на каждой странице. Если мы хотим создать страницу для отображения объекта заказа презентации, мы можем изменить модель презентации следующим образом:
public class PresentationOrder
{
public string PageTitle { get; set; }
public string UserName { get; set; }
public string ApplicationName { get; set; }
public int OrderID { get; set; }
public DateTime OrderDate { get; set; }
public string PrettyDate { get { return OrderDate.ToShortDateString(); } }
public string CustomerName { get; set; }
public Decimal OrderAmount { get; set; }
public string PrettyAmount { get { return string.Format("{0:C}", OrderAmount); } }
}
Этот дизайн может работать ... но что если мы хотим создать страницу, которая будет отображать список заказов? Свойства PageTitle, UserName и ApplicationName будут повторяться и станут неудобными для работы. Кроме того, что, если мы хотим определить некоторую логику на уровне страницы в конструкторе класса? Мы больше не можем этого делать, если создадим экземпляр для каждого заказа, который будет отображаться.
Композиция по наследству
Вот способ, которым мы могли бы пересмотреть модель представления заказа так, чтобы она стала истинной моделью представления и была бы полезна для отображения одного объекта PresentationOrder или коллекции объектов PresentationOrder:
public class PresentationOrderVM
{
// Application properties
public string PageTitle { get; set; }
public string UserName { get; set; }
public string ApplicationName { get; set; }
// Business properties
public PresentationOrder Order { get; set; }
}
public class PresentationOrderVM
{
// Application properties
public string PageTitle { get; set; }
public string UserName { get; set; }
public string ApplicationName { get; set; }
// Business properties
public List<PresentationOrder> Orders { get; set; }
}
Глядя на вышеупомянутые два класса, мы видим, что один из способов думать о модели представления - это то, что это модель представления, которая содержит другую модель представления в качестве свойства. Модель представления верхнего уровня (то есть модель представления) содержит свойства, которые относятся к странице или приложению, в то время как модель представления (свойство) содержит свойства, которые относятся к данным приложения.
Мы можем продвинуть наш дизайн дальше и создать класс модели базового представления, который можно использовать не только для PresentationOrders, но и для любого другого класса:
public class BaseViewModel
{
// Application properties
public string PageTitle { get; set; }
public string UserName { get; set; }
public string ApplicationName { get; set; }
}
Теперь мы можем упростить наш PresentationOrderVM следующим образом:
public class PresentationOrderVM : BaseViewModel
{
// Business properties
public PresentationOrder Order { get; set; }
}
public class PresentationOrderVM : BaseViewModel
{
// Business properties
public List<PresentationOrder> Orders { get; set; }
}
Мы можем сделать нашу BaseViewModel еще более пригодной для повторного использования, сделав ее универсальной:
public class BaseViewModel<T>
{
// Application properties
public string PageTitle { get; set; }
public string UserName { get; set; }
public string ApplicationName { get; set; }
// Business property
public T BusinessObject { get; set; }
}
Теперь наши реализации просты:
public class PresentationOrderVM : BaseViewModel<PresentationOrder>
{
// done!
}
public class PresentationOrderVM : BaseViewModel<List<PresentationOrder>>
{
// done!
}
