构建 ASP.net MVC 应用程序以使用存储库和服务
我最近开始阅读有关 ASP.net MVC 的文章，在对这个概念感到兴奋之后，我开始将我的所有 Webform 项目迁移到 MVC，但即使在遵循了所有好的建议之后，我也很难保持我的控制器瘦身（或者也许我只是不明白......）。 我处理的网站有文章、视频、报价……每个实体都有与之相关的类别、评论、图像。我使用 Linq to sql 进行数据库操作，对于每个实体，我都有一个存储库，并且对于每个存储库，我创建一个要在控制器中使用的服务。
所以我有 -
- ArticleRepository
- ArticleCategoryRepository
- ArticleCommentRepository
和相应的服务
- ArticleService
- ArticleCategoryService ...
你看图片。
我遇到的问题是，我有一个用于文章、类别和评论的控制器，因为我认为让 ArticleController 处理所有这些可能是有意义的，但现在我必须将所需的所有服务传递给控制器构造函数。所以我想知道我做错了什么。我的服务设计不正确吗？我应该创建更大的服务来封装较小的服务并在我的控制器中使用它们吗？或者我应该有一个文章类别控制器和一个文章评论控制器？
用户查看的页面由所有这些组成，要查看的文章、与之相关的评论、适用的类别列表……我如何有效地分解控制器以使其保持“瘦身” ”并解决我的头痛问题？
谢谢你！ 我希望我的问题不会太长而难以阅读......
I recently started reading about ASP.net MVC and after getting excited about the concept, i started to migrate all my webform project to MVC but i am having a hard time keeping my controller skinny even after following all the good advices out there (or maybe i just don't get it ... ).
The website i deal with has Articles, Videos, Quotes ... and each of these entities have categories, comments, images that can be associated with it. I am using Linq to sql for database operations and for each of these Entities, i have a Repository, and for each repository, i create a service to be used in the controller.
so i have -
- ArticleRepository
- ArticleCategoryRepository
- ArticleCommentRepository
and the corresponding service
- ArticleService
- ArticleCategoryService ...
you see the picture.
The problem i have is that i have one controller for article,category and comment because i thought that having ArticleController handle all of that might make sense, but now i have to pass all of the services needed to the Controller constructor. So i would like to know what it is that i am doing wrong. Are my services not designed properly? should i create Bigger service to encapsulate smaller services and use them in my controller? or should i have an articleCategory Controller and an articleComment Controller?
A page viewed by the user is made of all of that, thee article to be viewed,the comments associated with it, a listing of the categories to witch it applies ... how can i efficiently break down the controller to keep it "skinny" and solve my headache?
Thank you!
I hope my question is not too long to be read ...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是遵循单一职责模式的副作用。如果每个类都仅为一个目的而设计，那么您最终会得到很多类。这是一件好事。不要害怕它。从长远来看，在更换组件以及调试系统中哪些组件无法工作时，它将使您的生活变得更加轻松。
就我个人而言，我更喜欢将更多的域逻辑放在实际的域实体中（例如，article.AddComment(comment) 而不是articleCommentService.AddComment(article, comment)），但您的方法也非常好。
This is the side effect of following the Single Responsibility Pattern. If each class is designed for only one purpose, then you're going to end up with a lot of classes. This is a good thing. Don't be afraid of it. It will make your life a lot easier in the long run when it comes to swapping out components as well as debugging which components of your system aren't working.
Personally, I prefer putting more of my domain logic in the actual domain entities (e.g. article.AddComment(comment) instead of articleCommentService.AddComment(article, comment)), but your approach is perfectly fine as well.
我认为你正朝着正确的方向前进。问题是如何实例化你的服务？我不是 MVC.NET 专家，但做过大量面向服务的 Java 项目，并且正是您正在讨论的模式。
在Java领域，我们通常会使用Spring来注入单例bean。
1) 您可以使用依赖注入框架在.NET 中执行相同的操作。
2) 如果服务足够轻量级，您可以在方法中根据需要实例化服务。
3）您可以在每个控制器中创建静态服务成员，只要将它们编写为线程安全的即可，以减少对象流失。这是我在很多情况下使用的方法。
4）您甚至可以创建一个所有控制器都可以访问的简单的全局服务工厂，它可以只是一类单例。
还可以在 .NET 依赖注入上进行一些谷歌搜索。
I think you are headed in the right direction. The question is how to instantiate your services? I'm no MVC.NET guru, but have done plenty of service oriented Java projects and exactly the pattern you are discussing.
In Java land we would usually use Spring to inject singleton beans.
1) You can do the same thing in .NET, using dependency injection frameworks.
2) You can instantiate services as needed in the method, if they are lightweight enough.
3) You can create static service members in each controller as long as you write them to be threadsafe, to reduce object churn. This is the approach I use in many cases.
4) You can even create a simple, global service factory that all controllers access, which could simply be a class of singletons.
Do some Googling on .NET dependency injection as well.