n 层 ASP.NET MVC 应用程序中的验证
我正在寻找一些有关 ASP.NET MVC N 层应用程序验证最佳实践的实用/理论信息。
我正在开发一个 .Net 应用程序，该应用程序分为以下几层：
UI -> Mvc3
BLL层->所有业务规则。通过接口
DAL层与数据访问层和UI层解耦->使用存储库模式、EF4 和 pocos 进行数据访问
现在，我正在寻找一种良好、干净且透明的方式来指定我的验证规则。 到目前为止，以下是对此问题的一些想法：
UI 验证应该只对用户输入及其有效性负责。 BLL 验证应该处理有关应用程序业务规则的数据的有效性。
我主要关心的是如何以最有效的方式绑定 BLL 和 UI 验证。我想避免的是让 UI 检查一组验证并向 ModelState 手动添加错误。此外，我不想将 ModelState 传递给 BLL 并在那里填充。
我将不胜感激对此事的任何想法。
PS 这个问题应该标记为讨论吗？
I am looking for some practical/theoretical information regarding best practices for validation in asp.net mvc n-tier applications.
I am working on a .Net application divided into the following layers:
UI -> Mvc3
BLL layer -> all business rules. Decoupled from data access and UI layers through interfaces
DAL layer -> Data access with the repository pattern, EF4 and pocos
Now, I am looking for a nice, clean and transparent way to specify my validation rules.
Here are some thoughts on the matter so far:
UI validation should only be responsible for user input and its validity.
BLL validation should be handling the validity of the data regarding the application business rules.
My main concern is how to bind the BLL and UI validation in the most efficient way. One think I am would like to avoid is having the UI check in a collection of validation and adding manually errors to the ModelState. Furthermore, I do not want to pass the ModelState to the BLL to be populated in there.
I will appreciate any thoughts on the matter.
P.S. Should this question be marked as a discussion ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您的 BLL 层可能会在某种标准形式下返回验证错误，例如
Dictionary或其他一些自定义构建类型。控制器从视图接收视图模型，因此默认模型绑定器调用此视图模型的验证。如果此验证通过，接下来就是业务规则。视图模型映射到模型并传递到服务层。如果存在业务错误，服务将返回错误集合，可以使用控制器上的扩展方法将其插入到控制器中的ModelState中。Your BLL layer could return validation errors under some standard form like for example a
Dictionary<string, string>or some other custom built type. The controller receives a view model from the view so validation on this view model is invoked by the default model binder. If this validation passes next come the business rules. The view model is mapped to a model and passed to the service layer. If there are business errors the service would return a collection of errors which could be inserted into theModelStatefrom the controller using an extension method on the controller.