ViewModel与域实体

Question

在开始之前，我想说我知道ViewModel是什么，它的目的是什么，但是这种情况使它变得多余..请继续阅读:)

我正在开发一个ASP.NET MVC4应用程序，并且在PagedList，Domain Entities和ViewModels方面遇到了一些令人头痛的问题。

基本上，PagedList.MVC插件不能很好地与AutoMapper一起工作，我不得不做一些额外的工作来让它按照我想要的方式工作。

但后来我想，当需要有关域实体的所有属性时，我是否还需要一个ViewModel类？

当视图需要您的域实体上的每个属性时ViewModel有什么好处？

Answer 1

这可能是一个观点问题，我喜欢使用视图模型（和DTO），它具有以下好处：

• 我确定视图所需的所有数据都已加载而不是 代理等。
• 如果正确制作，DTO会提供一个小得多的图表来存储在缓存中（可能不适用于您的设置）
• 它允许我的视图模型与Domain对象有很大的不同，通常它们是复合的，并且非常宽松，可以自由地改变它们，而不会影响我的应用程序的任何其他部分。

现在要反击上述内容，很多人会这样做，你可以直接使用域对象。如果您发现自己的视图模型只是您网域的一对一相似内容而且您在上面看不到任何好处，我也可能会推荐这个。

通常取决于您的设置

• 您的团队
• 是什么让你富有成效
• 使用的工具，完全使用ORM
• 项目的规模和持续时间
• 经验
• 等等等

Answer 2

我想补充一点，对于小型项目，可以拥有自己的ViewModel并使用它。您可以稍后将实体分开，如果它需要它。

对于许多开发人员添加新图层而没有权衡利弊，后来他们开始注意到滞后然后怀疑发生。 MVC本身已经成为一个关注点。

有一个单独的DomainEntity解决了一个不同的问题，即UI不再将1对1映射到实体，请考虑以下内容。

Version 1
Domain              | Presentation  
--------------------------------
User.FirstName      | User.Name
User.LastName       |
User.PositionTitle  | User.PositionTitle

该示例演示了域和表示不再以1对1映射。将来，您可能会进行域修改，例如：

Version 2
Domain              | Presentation  
--------------------------------
User.FirstName      | User.Name
User.LastName       |
Position.Title      | User.PositionTitle

根据上面的示例（版本2），请注意未修改演示文稿。具有分离的域模型可提高界面稳定性。它甚至可以降低重构方案的更改成本。

ViewModel的优势

ViewModel的优点在于它将您的域与表示分离，当在大型项目中使用时，这种好处更加明显，其中不同的开发人员处理系统的不同部分（例如，单独的GUI团队）

  

一个小的改变需要改变许多类。

这是解耦实体的一个缺点，它会造成代码重复。额外的编码成本很高，其好处必须显而易见。