在MVC中映射M-> VM的最佳位置？

Question

我使用ASP.NET MVC 3。

我在服务器端遇到了至少两种映射Model-＆gt; ViewModel的方法：

• 在ViewModel类构造函数
中
• 内部控制器或指定的映射器类

我喜欢第一种方法，因为ViewModel属性声明及其映射在同一个地方，易于维护和单元测试。任何人都可以指定更多的利弊，或其他更好的做法吗？

Answer 1

ViewModel可以独立于任何源自数据库的模型类而存在。

我不建议将ViewModel填充代码放在Controller中，因为它不是控制器的责任（也是维护的噩梦）。

我的观点是从ViewModel映射到DBModel（反之亦然）是ViewModel的责任，因此我的所有ViewModel类都实现了两个成员：

public static TViewModel FromDBModel(TDBModel dbModel);

public void ToDBModel(TDBModel dbModel);

第一个是Controller在返回View时调用的静态方法。静态方法构造ViewModel的实例并相应地设置其成员。

实例ToDBModel方法传递一个构造的DBModel实例（在检索或更新数据时由Repository构造，或在插入新数据时由控制器构造）。

HTH。

编辑：请注意，许多人发誓如AutoMapper（使用反射和其他技巧来自动化DBModel＆lt; - ＆gt; ViewModel映射过程）等库。我不是自动映射的粉丝，因为它取消了开发人员的控制权，当我不得不了解映射器如何工作以及如何让它映射非平凡的操作时，我不认为它会花费我的时间。 YMMV。

Answer 2

我倾向于将实体和视图模型分开，以便它们彼此不知道。这是为了在测试控制器和映射自身时改进封装并最小化依赖性。见Separation of concerns。

相反，我会编写类来自己执行映射（如果它很简单）或使用AutoMapper并在控制器中使用该方法。对于具有数十或数百个数据库实体和视图的大型系统，我倾向于倾向于AutoMapper。自己编写映射可能会变得非常繁琐且容易出错。你必须平衡自己编写的价值与实施给企业的价值。毕竟，如果我们想要了解每个框架的所有内容，我们每个人都会编写自己的.NET框架版本。 :)

也就是说，对某些系统使用视图模型可能没什么好处，特别是那些视图中的“字段”与数据库实体[又称典型的CRUD]之间存在一对一映射的系统。当我看到这一点时，我通常会感到畏缩，但考虑到系统的时间框架和复杂性，它总是一个选项。

然后有一种情况是您使用ASP.NET MVC来公开API。在这种情况下，您的实体的“application / json”和“text / xml”表示只是“视图”。视图模型通常用于过滤外部演示文稿中的敏感和不必要的数据。在这种情况下，由于可能存在针对同一实体的若干表示（及其版本）的事实，映射变得相当复杂。但是，这似乎超出了OP。