MVC3 IsValid 和业务逻辑层
我在我的应用程序中使用 MVC3，并且有一个关于验证的问题。我有一个与 Web 层分离的业务逻辑层，其中有一个类似 CreateUser 的函数，它创建一个新用户供应用程序使用。我希望可以在两个地方访问此函数：1）在使用它的控制器中的某个位置，2）在将数据插入系统的“设置数据”程序中。
我想利用诸如 ModelState.IsValid 之类的东西来检查所有基本验证，但这对我的设置数据模式（或任何其他不经过 MVC 的模式）没有帮助。有什么方法我仍然可以利用此代码，但将所有验证包含在我的 BusinessLogic 层而不是控制器中，而不让 BusinessLogic 层依赖于 MVC？
谢谢。
I am using MVC3 for my application and I have a question about validation. I have a Business Logic layer that is separate from my web layer where I will have a function like CreateUser, which creates a new user for the application to use. I want this function to be accessible in two places: 1) Somewhere in a controller that makes use of it and 2) in a "Setup Data" program that inserts data into the system.
I want to make use of things like ModelState.IsValid to check for all basic validation, but this won't help me for my Setup Data mode (or any other mode that doesn't go through MVC). Is there any way I can still leverage this code, but to contain all validation in my BusinessLogic layer instead of in the controller without having the BusinessLogic layer rely on MVC?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
看起来这篇关于服务层的文章有我需要的< /a>.仍然欢迎其他建议。谢谢。
It looks like this article about Service Layers has what I need. Other suggestions are still welcome. Thanks.
请注意，有关服务层的文章仍然意味着您需要对 MVC 程序集的依赖。最近我自己对此进行了一些思考，现在我认为将事物尽可能分开是一个很好的设计。在我的模型程序集中，我有一个服务文件夹，在其中，例如，从 Create() 例程中，我验证并抛出自定义异常。
服务层并不关心这些异常被谁或如何消耗。在您的 MVC 应用程序中，将它们映射到模型状态错误集合或其他内容中。您的设计更加可靠，因为您的模型组件不依赖于某些验证运行程序适当使用 MVC 验证属性、集合等。
我还注意到该文章提到了存储库。我知道它现在很流行，但如果您已经在使用像实体框架这样的 ORM，那么存储库实际上只是一个 Reposity 是新的 Singleton。
Note that the article on service layers still means that you need a dependency on the MVC assembly. After wrestling a bit with this myself recently, I'm now of the opinion that keeping things as separate as possible is a good design. In my model assembly, I have a services folder wherein from, say, a Create() routine, I validate and throw custom exceptions.
The service layer doesn't care who or how these exceptions are consumed. In your MVC app, map them into model state errors collections or whatever. Your design is all the more solid because your model assembly doesn't depend on some validation runner making appropriate use of MVC validation attributes, collections, etc.
I also noticed the article mentions a repository. I know it's all the rage these days but if you're already using an ORM like Entity Framework, a repository is really just a DAO. Reposity is the new Singleton.