领域模型（Domain Model ）和视图模型（View Model）有什么不同呢？
在ASP.NET MVC的应用程序中经常可以可以看到View Model，经常我们都认为领域模型和视图模型是同一个东西。这特别是把领域模型包含在数据传输对象DTO里的时候，例如使用Entity Framework之类的ORM工具生成的实体。在这种情况下，领域模型和视图模型包含的实体非常相似，都是一些简单的CRUD操作。
这些实体有许多属性，有相同或类似的名称，你可以很容易地映射领域实体对应视图模型中的一个属性。不过，这些相似的属性也可能略有不同，例如类型或者格式。例如，用户填写的用户界面的一个属性，他在视图模型里可能是一个“Nullable”的。另一方面，领域实体可能需要一个经过验证的合法的值，所以需要一个在用户界面的领域模型之间的转换。另一个例子是，用户界面可能会显示一个滑块，用于用户选择多少天以后提交他的订单。在这种情况下，视图模型可能使用一个整数属性来表示，领域模型通常是一个日期值。
视图模型通常只包含领域模型的一个子集，而且只包含界面上所需要的属性。此外，视图模型可能是一个领域模型树的扁平版本，例如，一个Customer实体有一个Address，而这又是一个整体，它包含街道地址，邮政编码，国家等。一个Customer 视图模型用于显示数据，将地址数据拉平填充到视图模型类里。
此外如果一个View需要同时处理几个领域模型，View Model就是这几个Domain Model的总和。领域模型和视图模型之间有很多相似的地方，我们经常干脆就把Domain Model当作View Model来使用了。
上面讨论了领域模型和视图模型的相似性，我们来看看都有几种方式把领域模型转换为视图模型，通常有3种方法：
- 把领域模型当作视图模型来用，也就是领域模型就是视图模型，大部分都是这么用的。
- 视图模型里面包含一个领域模型，定义一个视图模型，里面包含了一个领域模型，通过属性方式进行访问。
- 将领域模型映射到视图模型，领域模型并没有直接映射到视图模型，需要处理这种映射关系。
我们不建议直接把领域模型实体暴露给视图，因为有许多细微之处，可能导致您混合业务和表示层的逻辑，无论是领域实体的属性显示还是业务的验证规则，这都是应用程序处理的不同方面。直接将你的领域模型作为Conroller上的处理参数面临着安全风险，因为Controller或者Model binder必须确保属性验证和用户不能修改她自己不能修改的属性（例如，用户手动更新了一个隐藏的输入值，或增加一个额外的属性值，而这个并不是界面上的元素，但却正好领域模型实体的属性，这种风险叫做“over-posting”），即使对当前版本的领域模型做了正确的验证，领域模型将来可能做了变更修改，并没有出现编译错误或者警告，可能导致新的风险。
我们应当避免使用前两种方法将领域模型转换成视图模型，推荐使用第三种方法，定义单独的视图模型类。做这种领域模型到视图模型的转换工作是一种重复性的工作，已经有几个工具可以帮助你来完成这项工作。最常用的一个工具就是.NET 社区的开源项目AutoMapper。