ASP.NET MVC 中模型验证的最佳实践有哪些？
我对有关客户端验证或模型绑定的答案不感兴趣。实际上，这个问题可以适用于 MVC 之外的任何数据访问类库，但我认为问题是相似的。
我当前使用存储库模式对我的实体（模型）进行数据访问。目前，存储库处理所有 CRUD 操作，但我认为我希望我的模型能够负责保存自身以便进行验证。我应该如何处理这个问题？
我可以在我的模型中添加一个存储库可以调用的 IsValid 方法，然后可以在存储库保存模型之前运行我的所有业务逻辑，但是没有什么会强制存储库调用此验证逻辑，对吗？
如果我希望模型有一个 Save 方法，那么他们保存自己的正确方法是什么？他们不应该回拨到存储库，不是吗？
关于我应该如何处理这个问题有什么想法吗？
谢谢！
I'm not interested in answers concerning client side validation or model binding. Really, this question could apply to any data access class library outside of MVC, but the issues are similar, I think.
I'm using the Repository pattern currently for data access with my entities (models). Currently the repositories handle all of the CRUD operations, but I think I'd like for my models to be responsible for saving themselves in order to do validation. How should I handle this?
I could add a IsValid method in my models that the repositories could call that could then run all of my business logic before the repository saves the model, but then nothing FORCES the repositories to call this validation logic, right?
If I want the models to have a Save method, then what's the proper way for them to save themselves? They shouldn't call back up to the Repository should they?
Any thoughts on how I should handle this?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
允许模型验证保存操作本质上没有什么问题；甚至可以返回 false 或抛出异常。当您必须向用户提供反馈以说明为什么他们输入的数据无效时，就会出现困难。
验证可以而且应该首先在视图中进行。这可以在客户端使用 jQuery 库轻松完成。但用户提交后，数据仍然必须在服务器端进行验证，如果数据仍然存在问题，您仍然必须向用户提供解释。
由于需要提供用户反馈，因此可以在视图模型对象中有效地提供此类服务器端验证。该数据对象有两个用途：首先，它将视图和控制器之间传递的数据封装在强类型对象中。其次，它提供了一个方便的位置来执行验证，而不需要控制器或视图中的验证逻辑。
如果使用Linq to SQL，则视图模型可以是实际数据模型类的扩展，使用C#中的partial关键字。这允许您使用生成的 Linq to SQL 类的现有 ORM 功能，同时添加额外的验证功能。我假设这在实体框架和其他 ORM 中的工作方式相同。
视图模型在 NerdDinner 教程中进行了描述：
http://nerddinnerbook.s3.amazonaws.com/Part6.htm
验证过程此处描述：
http://nerddinnerbook.s3.amazonaws.com/Part3.htm
There's nothing inherently wrong with allowing the model to validate save operations; it is even feasible to return false or throw an exception. The difficulty arises when you must then provide feedback to the user as to why their entered data is not valid.
Validation can and should occur in the view first. This can readily be done client-side using jQuery libraries. But the data must still be validated server-side after the user submits, and if there are still problems with the data, you must still provide an explanation to the user.
Because of the need to provide user feedback, server-side validation of this sort can be effectively provided in a View Model object. This data object serves two purposes: first, it encapsulates the data that passes between the view and the controller in a strongly-typed object. Second, it provides a convenient place to perform validation, without requiring validation logic in either the controller or the view.
If Linq to SQL is used, the View Model can be an extension of the actual data model class, using the partial keyword in C#. This allows you to use the existing ORM capabilities of the generated Linq to SQL class, while tacking on the additional validation functionality. I assume that this works the same way in the Entity Framework, and other ORMs.
View Models are described in the NerdDinner tutorial here:
http://nerddinnerbook.s3.amazonaws.com/Part6.htm
The validation process is described here:
http://nerddinnerbook.s3.amazonaws.com/Part3.htm