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

Question

我使用ASP.NET MVC 3.

我遇到在服务器端用于映射模型 - >视图模型至少2的方法：

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

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

Answer 1

ViewModels可以独立于任何数据库发起的模型类而存在。

我不建议把视图模型人口代码控制器内部，因为这何尝不是控制器的响应（同时也是一个维护的噩梦）。

我的看法是，映射从视图模型来DbModel之后（反之亦然）是视图模型的责任，所以我所有的ViewModel类实现两个成员：

public static TViewModel FromDBModel(TDBModel dbModel); 

public void ToDBModel(TDBModel dbModel); 

首先是一个静态方法控制器在返回视图时调用。静态方法构造ViewModel的一个实例并相应地设置它的成员。

实例ToDBModel方法传递一个构造实例DbModel之后（或者检索或更新数据时，由所述存储库构成，或插入新的数据时，由所述控制器构造的）。

HTH。

编辑：请注意，许多人发誓的图书馆，如AutoMapper（它使用反射和其他技巧来自动化DBModel < - > ViewModel映射过程）。我不喜欢自动映射，因为它远离开发人员的控制权，我不知道它让我花时间学习映射器的工作方式，以及如何将映射器映射到非平凡的操作。因人而异。

Answer 2

我会倾向于保持实体和视图模型分开，使得他们不知道对方。这是为了在测试控制器和映射本身时改进封装并最小化依赖关系。见Separation of concerns。

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

这就是说，有可能使用图模型对于一些系统没有什么好处，特别是那些有一个一对一的映射在视图中“田”和数据库实体[又名典型CRUD]之间。当我看到这件事时，我通常会畏缩不前，但鉴于系统的时间框架和复杂性，它总是一种选择。

然后有一个情况下，当您使用ASP.NET MVC暴露的API。在这种情况下，实体的“application/json”和“text/xml”表示只是“视图”。视图模型通常使用来自外部演示文稿的过滤器敏感和不必要的数据。在这种情况下，映射变得相当复杂，因为对于同一个实体可能有几个表示（及其版本）。但是，这似乎在OP之外。