编辑：我在我的博客上更新了此答案：
http://www.samwheat.com/post/The-function-of-ViewModels-in-MVC-web-development
我的回答有点冗长，但是我认为将视图模型与其他常用模型进行比较很重要，以了解它们为什么不同以及为什么必要。
总结并直接回答所提出的问题：
一般来说，视图模型是一个对象，其中包含呈现视图所需的所有属性和方法。视图模型属性通常与诸如客户和订单之类的数据对象相关，此外，它们还包含与页面或应用程序本身相关的属性，例如用户名，应用程序名称等。视图模型提供了一个方便的对象，可以传递给渲染引擎以创建一个html页面。使用视图模型的许多原因之一是，视图模型提供了一种对某些表示任务进行单元测试的方法，例如处理用户输入，验证数据，检索数据以供显示等。
这是实体模型（也称为DTO的a.ka.模型），表示模型和视图模型的比较。
数据传输对象又称“模型”
数据传输对象（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); } }
}
查看模型
视图模型类似于表示模型，它是用于渲染视图的后备类。但是，它的构造与Presentation Model或DTO完全不同。视图模型通常包含与表示模型和DTO相同的属性，因此，它们常常彼此混淆。
视图模型的特征：
•是用于呈现页面或屏幕的单一数据源。通常，这意味着视图模型将公开页面上任何控件需要正确呈现自身的每个属性。使视图模型成为视图的单一数据源可以极大地提高其功能和单元测试价值。
•是复合对象，其包含由应用程序数据以及应用程序代码使用的属性组成的属性。当设计视图模型的可重用性时，此特性至关重要。下面的示例对此进行了讨论。
•包含应用程序代码。视图模型通常包含在渲染过程中以及用户与页面交互时调用的方法。该代码通常与事件处理，动画，控件的可见性，样式等相关。
•包含调用业务服务以获取数据或将其发送到数据库服务器的代码。该代码通常被错误地放置在控制器中。从控制器调用业务服务通常会限制视图模型对单元测试的有用性。需要明确的是，视图模型本身不应包含业务逻辑，而应调用包含业务逻辑的服务。
•通常包含属性，这些属性是其他页面或屏幕的其他视图模型。
•写为“每页”或“每个屏幕”。通常为应用程序中的每个页面或屏幕编写一个唯一的视图模型。
•通常是从基类派生的，因为大多数页面和屏幕都具有相同的属性。
查看模型组成
如前所述，视图模型是组合对象，因为它们在单个对象上组合了应用程序属性和业务数据属性。视图模型上常用的应用程序属性示例包括：
•用于显示应用程序状态的属性，例如错误消息，用户名，状态等。
•用于格式化，显示，样式化或动画化控件的属性。
•用于数据绑定的属性，例如列表对象和保存用户输入的中间数据的属性。
以下示例说明了为什么视图模型的复合性质很重要，以及如何最好地构建高效且可重用的视图模型。
假设我们正在编写一个Web应用程序。应用程序设计的要求之一是必须在每个页面上显示页面标题，用户名和应用程序名称。如果我们要创建一个页面来显示演示文稿订单对象，则可以如下修改演示文稿模型：
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!
}
