ASP.NET MVC-用户输入和服务/存储库-在哪里进行验证?

提交表单时,我通常在控制器操作中进行基本验证(必填字段、电子邮件格式等)。然后,我让业务层处理需要业务知识的验证。我通常也会仔细检查业务层中的基本内容,因此,如果我通过web服务公开该逻辑,或者稍后在另一个应用程序中使用它,我仍然会在最重要的地方进行验证(IMO)。

• MVC & MS Validation Application Block
• MVC & Data Annotation Validators
• Form Validation video

就我个人而言,我已经将验证添加到我的服务层对象(前两个链接)。这边,如果 任何 控制器决定调用我的服务方法。。逻辑全部检查并装箱在一个位置。 干的 .

嗯!

查看以下博客文章

http://blog.codeville.net/2008/09/08/thoughts-on-validation-in-aspnet-mvc-applications/ http://www.emadibrahim.com/2008/09/08/client-server-side-validation-in-aspnet-mvc/

看看S#arp架构项目。对模型进行验证,以确保没有实体以无效状态持久化到数据库。它通过使用NHibernate.Validator并将其附加到NHibernate的保存和更新事件来实现这一点。

就个人而言,这种方法对我来说最有意义,因为您不必在多个控制器中复制验证逻辑。

我担心我的帖子不会得到回复,很高兴我错了!

我以前读过这些链接,但可能是一个多月前,用我现在了解的内容重新阅读它们非常有帮助。我真的很喜欢史蒂夫·桑德森(Steve Sanderson)关于滑动比例的帖子,但我希望他能展示一个在正确的角度验证某些东西的例子。

他在博客中举了一个例子:“‘用户名必须是唯一的’可能会在数据库中强制执行”。那么这会是这样的:

public static void SavePerson(Person person)
{
    // make sure it meets some format requirement
    // in this case the object is responsible for validation and the service layer is the caller
    person.EnsureValid();

    // todo: action to verify username is unique by checking database
    // in this case the service layer is responsible for calling and implementing validation

    // todo: action to save to database
}

我所关心的另一个问题是服务层开始使用验证逻辑。也许把它分到不同的班级或者别的什么?在我的例子中,一些验证逻辑可能在服务之间共享,因此我想考虑一种实现这一点的简单方法。有趣的事情去想!

Emad Ibrahim的链接非常好,因为一旦我开始进一步了解这个过程,我将寻找一种方法,使用相同的规则集生成javascript客户端验证,而无需重复代码。他已经有了:)

还有一个我喜欢的链接(在我看到Emad用BLL回复Steves的帖子后在Google上搜索了一下,不知道这是什么意思……嗯):

http://en.wikipedia.org/wiki/Business_logic_layer

所以我不知道,但我认为这就是我要写的模型:处理数据交互的业务流程对象,以及作为逻辑模型而不是数据库模型的业务实体。我想我需要开始阅读一些更基本的模式和实践来更好地理解这些概念(看起来很多都是Java人写的,而不是网络人写的)。也许是时候退一步了:)

我在最近的一个项目中遇到了同样的问题。首先,为了重申这个问题,我试图遵循DDD的以领域为中心的方法。我将实体组合成可以自我验证的聚合,存储库在保存时验证有效性。UI还可以从聚合中获取有效性信息,以便向客户端显示错误反馈。一般的方法是尽可能多地利用ASP.NET MVC的模型绑定和验证/表单UI帮助程序。这将创建简单的UI流:1)绑定,2)验证,3)如果有效,保存,否则重新填充视图。

然而,当涉及DDD服务时,如何利用ASP.NET MVC和这个简单的流程还不是很明显。最初,我开发了以下服务:

public class SomeProcessService 
{
  public Result Execute(int anAggregateID, int anotherAggregateID, string someData) 
  {
    // validate input

    // if invalid, return failures

    // else 
    //   modify aggregates
    //   using (transaction)
    //   {
    //     save aggregates
    //     commit
    //   }

    // return success
  }
}

问题在于,验证和保存在方法中是密不可分的。为了利用MVC模型绑定,我们需要一些作为绑定到的模型的东西。我正在对此进行重构:

public class SomeProcessService 
{
  public class Request : IValidateable
  {
    public int AggregateID {get;set;}
    public int AnotherAggregateID {get;set;}
    public string SomeData {get;set;}

    public Result Validate() 
    {
      // validation
    }
  }

  public void Execute(Request request) 
  {
    // validate input by calling request.Validate()

    // if invalid, throw new ValidationException(request)

    // else 
    //   modify aggregates
    //   using (transaction)
    //   {
    //     save aggregates
    //     commit
    //   }

    // return success
  }
}

这改变了 Parameter Object pattern 分离方法输入验证。我可以绑定到控制器中的SomeProcessService.Request对象,并从中获取验证信息。如果一切正常,我将从控制器使用请求对象作为参数启动服务调用。这种方法似乎很高兴地将DDD服务与ASP.NET MVC验证需求结合起来。