问ASP.NET MVC --数据库实体还是ViewModels？

EN

毫无疑问，在你的视图中使用视图模型，并使用像AutoMapper这样的东西来轻松地从实体创建视图模型。

缺点：

1. 有时感觉像是在复制代码，特别是当视图模型和实体具有完全相同的属性

时

优点：

1. 您通常需要以更简单的格式表示对象(通常称为展平)，但您需要服务器端的完全保真度。这允许你在两者之间转换，而不会搞乱你的域模型。cruft.
2. Aggregate根通常有很多值对象和额外的与特定视图无关的实体，在视图模型中省略它们会让你更容易使用。试图在一种类型上平衡这两种需求可能会造成巨大的混乱。

传统观点认为，您永远不应该在视图中使用原始数据库实体。就像任何规则一样，如果你很了解你的实体并了解后果，它就会被打破，但有非常好的理由不去违反规则，特别是在团队中工作时，以及在未来将由可能不像你一样理解规则或实体的人维护的代码中。主要原因是：

1. ORM延迟加载。想象一下，你的客户有一个延迟加载的集合订单。您将Customer传递给View，它将遍历订单。您将在Orders表上获得一个N*1 select。但这也意味着您的数据库连接仍然需要在视图中打开。有一种模式是，人们使用“每操作事务”来处理Action_Executed事件中的数据库上下文，该事件在呈现视图之前发生。因此，您可以在数据库被释放后尝试访问该数据库。即使您现在不这样做，将来也可能会有人决定实现该模式，因为ViewModel的fashionable.
2. The关注点与db模型不同。例如，您通常使用验证属性来修饰您的ViewModel属性。这些通常是不同的，或者只涉及UI而不涉及db。如果您绑定到数据库实体，您会发现所有这些UI问题都会污染您的DB entities.
3. Related to 2-。ViewModel的要求可能需要计算或派生的属性。例如，从名字和姓氏构造的全名。这类东西最好保存在ViewModel.
4. You中，这样就可以从数据库中分离出来对ViewModels进行单元测试。 ViewModels最终可能会包含相当多需要进行单元测试的逻辑。如果它没有绑定到您的数据库(就像EF实体一样)，这将更容易测试。

通常，创建和维护ViewModels (即使没有AutoMapper)也不是一种开销，您会发现这是一种更好的整体开发模式。除了最简单的情况(例如，静态数据的查找列表)之外，我都会推荐它。

我相信使用视图模型是唯一的方法，所以对象关系管理实体没有优点：)视图模型不仅为视图提供数据，而且还定义视图应该看起来是什么样子(通过定义模板)，或者它应该如何验证(通过添加数据注释或实现IDataErrorInfo)。

使用视图模型的：

优势：

entities.

• View

• 视图模型仅包含视图所需的属性，不包含其他属性。

• 视图模型可能包含使用数据注释的特定验证规则，或者entities.

• View模型可以将来自不同数据库的值合并到文档中，并且不绑定到任何framework.

• View模型保护您免受包含表单中未提供但包含在

中的值的伪造发布的影响。

• 可以轻松地为视图模型指定显示模板，并使用DisplayFor或EditorFor帮助器在许多地方重复使用这些模板。

使用对象关系管理实体的：

缺点：

• 对象关系映射实体已经包含了数据注释，这可能会影响您的验证。示例: user中的密码字段可以标记为Required，但在仅更改基本用户信息时不是必需的。
• ORM实体与框架(实体框架)紧密相关，可能不容易在其中实现规则。
• ORM实体可以包含多个视图的属性，但很难为不同视图分隔验证规则。
• 使用延迟加载的ORM实体可导致在呈现视图时执行
• 查询。它不应该对ORM实体进行happen.
• Using，这会导致在小的查询上使用大型的SQL查询。当您想要显示带有名字和姓氏的下拉列表时，您应该只从数据库中检索名字和姓氏，而不是整个实体。