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

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
    {
        ...
}

如果切换到ViewModels,您应该让框架通过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; }
}

在你的Post Action中你可以做类似的事情：

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).

通常我的Business Objects使用ViewModel的属性来考虑它们(只是用于防止错误注入的有用的属性)并执行脏/重工作.

这可能不是一切的完美解决方案,但我注意到应用这种模式(并强迫团队的其他成员也这样做),正在形成一个良好的代码库.
是的,我们还远没有完美,我只想写一次语义和正式检查,但这就是网络现在的运作方式.

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

PS：一旦你选择了一个模式,无论如何都坚持下去.

编辑:(长评不是不)

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

我的IsValid()方法只保存业务检查(例如,给定一个ID,它检查某个表中是否存在真实存在,或者如果他能够实际访问某些数据则给出用户名检查).

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

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

所以绝对是一个更多的工作,但我认为最好投入几个小时,而不是浪费几天来进行维护/改进.

如今,编程似乎被简化为一种“忘掉”的活动,(由于减少了时间/预算,或者仅仅因为我们完成了我们的任务,然后更换了员工),但是编码的每一行,将来都需要某种维护,所以最好保持订购和清洁,更喜欢维护轻松,防止发展速度.