asp.net-mvc - 使用 viewmodel 时的 asp.net mvc 验证

Question

最近我决定使用 View 模型而不是 EF EntityObjects。 我确信 GET 请求不会有问题，但我想知道如何处理创建和更新操作。 我读了很多讨论并决定我将采取行动 this way 。 但又出现了一个问题:

1) 当我使用带有注释的 EF EntityObjects 时，验证逻辑存储在一个位置，但如果我在不同的项目中有不同的 View 模型，那么我将不得不复制验证规则。这不是违反了DRY原则吗？

2)我读过几篇关于 View 模型和验证的文章，其中人们建议验证 View 模型中的输入和域模型中的业务规则，但我无法意识到如果我的操作有，我如何调用域模型中定义的验证 View 模型作为参数:

public class MyDomainModel : IValidatableObject
{
    public string Title;

    // validation of business rules
}

public class MyViewModel
{
    [Required]
    public string Title;
}

public ActionResult Edit(MyViewModel item)
{
    if (ModelState.IsValid) // MyViewModel's rules are validated not MyDomainModel's
    {
        ...
}

Answer 1

如果您切换到 ViewModel，您应该让框架通过 ViewModel 类中的 DataAttributes 执行验证。这只是对输入的正式检查，然后您应该根据业务规则进行验证(有时仅使用数据注释不可能覆盖所有场景)，如果出现错误，请将其添加到模型状态中。

示例:

public class MyViewModel 
{
   [Required]
   [StringLength(20)]
   [RegularExpression("whatever")]
   public string Foo { get; set; }

   [Required]
   public int Bar { get; set; }

   public bool AFlagNotModifiableButImportant { get; set; }
}

在您的后期操作中，您可以执行以下操作:

public ActionResult Sample (MyViewModel Obj) 
{
    if (!ModelState.IsValid) {
       return View(Obj);
    }
    // Complex business logi checks in here
    MyBusinessObj BsnObj = new MyBusinessObj(Obj);
    if (!BsnObj.IsValid()) {
      ModelState.AddModelError(string.Empty, "A veery bad error");
      return View(Obj);
    }
    // Perform Heavy Business Logic which creates a new ViewModel (eg. setting the flag property in order to show something important at view level)
    MyViewModel NewOne = BsnObj.DoIt();
    // Return a view with the new Model (can be whatever you want)
    return View(NewOne);
}

显然我把它保持得非常简单。 遵循这种模式肯定会在代码方面增加一些开销，但是必须在客户端(仅对输入进行形式验证)和服务器端(形式和语义验证)进行检查。我更喜欢在业务程序集中拥有所有语义，将正式检查留给 MVC 不引人注目的验证引擎(在我看来只是一些 UI 糖，是的，我讨厌 Javascript)。

通常我的业务对象使用 ViewModel 的属性，考虑它们是只读的(只是有用的属性来防止错误的注入(inject))并完成肮脏/繁重的工作。

这可能不是解决所有问题的完美解决方案，但我注意到应用这种模式(并迫使团队的其他成员也这样做)可以产生良好的代码库。 是的，我们离完美还很远，我想只编写一次语义和形式检查，但这就是网络现在的工作方式。

如果您需要进一步的建议或者我完全误解了您的问题，请告诉我。

PS:一旦选择了一种模式，无论如何都要坚持下去。

编辑:(长评论是不行的)

在构造函数中，我通常将映射应用于需要更改的字段，我尝试将 ViewModel 属性视为只读，以避免不必要的修改。

我的IsValid()方法只保存业务检查(例如，给定一个ID，它检查某个表中是否真实存在，或者给定一个用户名，检查他是否实际上可以访问某些数据)。

这只是 ViewModel 验证(对我来说只是语法 => 字符串是字符串，整数是整数，正数 >= 0，尊重字符串长度，满足范围等等)和实际业务有效性之间的分离(语义 => 用户可以访问某些数据，对象在应用程序范围内有效)。

当然，业务验证层也可以很简单(或者根本不存在)，我更喜欢将它们分开以实现可重用性(通常我的业务逻辑在 MVC 应用程序和 WPF应用程序)。这是一些额外的工作，但从长远来看，它会带来更好的返回，我可以在任何地方使用我的复杂业务逻辑。 (与 Banks 合作，这是最大的目标。仅更改一个程序集中的逻辑，例如添加对某些内容的新检查，并确信使用该程序集的每个应用程序都是最新的)。

所以这肯定是更多的额外工作，但我认为最好在之前投入几个开发时间，而不是最近浪费几天时间进行维护/改进。

如今的编程似乎已简化为一种一劳永逸的事件(由于时间/预算的减少或仅仅因为我们完成任务然后更换员工)，但是编码的每一行都需要某种维护 future ，所以最好保持事物有序和干净，更喜欢维护方便而不是开发速度。