asp.net-mvc - 何时使用 ViewModel 而不是 Model？

Question

我有一个名为 Customer 的业务模型，它具有许多必需的属性(通过 DataAnnotations)和其他验证规则。

我有一个 View ，旨在允许编辑客户的地址字段。

我遇到的问题是我想要一个强类型 View ，但我无法在此处使用 Customer 类型。由于 View 只会编辑地址数据，因此不会返回 Customer 对象验证所需的任何其他必需数据。

这表明我应该使用 ViewModel。但是，有许多业务规则适用于 Customer 上与地址相关的属性，我必须在新的 ViewModel 上复制这些规则(地址长度、邮政编码、状态格式等)。它们需要重复，因为客户端验证(我正在使用 xVal)需要该信息才能运行。

我觉得我已经达到了 catch-22 情景。 DRY 告诉我，我不应该在我的模型已经拥有的 ViewModel 上复制我的业务规则，但另一方面我不能使用该模型，因为它永远不会验证。

在这种情况下，最佳做法是什么？

选择的路径

我最终选择的解决方案是 ViewModel 路径。为了获得我需要工作的验证，根本没有其他实用的方法。

但是，使用 ViewModel 提出来却无法消除一些粗糙的地方。我重构了一些模型以使用包含我知道将在 ViewModel 中重用的属性的接口(interface)。由于 ViewModel 现在可以使用与模型相同的接口(interface)，因此我可以执行以下操作:

 public ActionResult Edit(AddressViewModel address)
 {
      if(!ModelState.IsValid)
          return View();

      var customer = Customer.Load(address.CustomerId);
      UpdateModel<IAddress>(customer);

      // more stuff ....
 }

这为我节省了使用自动映射器的步骤。

我在下面选择的答案(由 Wyatt Barnett 提供)我觉得对大多数情况都很好，我在我拥有的其他项目中使用它，特别适用于 Linq-to-Sql。

Answer 1

我遇到了同样的问题，复杂的模型类不能很好地处理简单的 View 和模型绑定(bind)。我也碰巧在使用 xVal。我遇到的窍门是使用 Validation Buddies覆盖 DRY 角度以进行基本验证，然后使用 AutoMapper 将事物推回到成熟的模型类中。然后，我可以运行第二轮服务器端验证，以涵盖需要访问数据库等的更复杂的位。