具有多个存储库和服务的.NET MVC 控制器？
看看我的控制器（我正在使用依赖注入来管理依赖项）：
public RoleController(IRoleRepository roleRepository, ISiteRepository siteRepository, IUserRepository userRepository, IDbContext dbContext)
{
_roleRepository = roleRepository;
_siteRepository = siteRepository;
_userRepository = userRepository;
_dbContext = dbContext;
}
拥有一个具有许多依赖项的类是一种代码味道吗？正确的？
但是，在我的示例中，我需要将 Users 和 Sites 关联到 Role 中，然后我需要这些依赖项来执行此关联。
邮件列表上的一些人告诉我，有太多依赖项可能表明出现了问题。但我看不到其他办法。我把我的职责分开了，有什么情况我不知道该如何对待？有什么问题吗？
更新：
我需要存储库和DbContext，因为DbContext是我的工作单元，存储库不保存。
此示例是一个简单的 CRUD，具有一些其他功能，例如视图中与 GRID 的关联。
更新 2：
我使用的架构中，我的 UI 层是 MVC。
Look at my Controller (I'm using Dependency Injection to manager dependencies):
public RoleController(IRoleRepository roleRepository, ISiteRepository siteRepository, IUserRepository userRepository, IDbContext dbContext)
{
_roleRepository = roleRepository;
_siteRepository = siteRepository;
_userRepository = userRepository;
_dbContext = dbContext;
}
Having a class with many dependencies is a code smell? Right?
But, In my example I need to associate Users and Sites in a Role, then I need to these dependencies to doing this association.
Some people on a mailing list I was told that having too many dependencies is a sign that something is probably wrong. But I see no other way. I separated my responsibilities, there is something in that situation I do not know how to treat? Is something wrong?
Update:
I need Repositories and DbContext because DbContext is my UnitOfWork, repositories don't save.
This example is a simple CRUD with some other functionalities like Associations in the View with a GRID.
Update 2:
I'm using a architecture where my UI Layer is the MVC.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不认为这是一件坏事，因为您使用良好的 DI 框架来管理依赖项（即不使用
但是，如果您确实想限制这种特定情况下的依赖项数量，那么创建一个
MembershipService可能是有意义的，它可以完成与相关的所有工作>用户，站点和角色。然后，它将依赖于这三个存储库，并且您的控制器将仅依赖于成员资格服务。响应您的更新：您可以将工作单元（即数据库上下文）注册为“每个网络请求”单例 - 这对于 Castle Windsor 和许多其他 DI 框架是可能的。然后你可以让你的存储库依赖它并完成所有更改，并让控制器依赖它进行保存，它们都将获得 DI 框架传递给它们的相同实例。
I don't believe it's a bad thing, given that you manage dependencies with a good DI framework (i.e. not by using poor man's DI). This way, you explicitly say that the controller will need all these things, because it will. (Note that in many other parts of your application, this might not be a valid argument - the controller is special in the way that it is where you control and direct the program flow, so there's a natural explanation why it needs to see lots of parts of the application...)
However, if you really want to limit the number of dependencies in this specific case, it could make sense to create a
MembershipService, which does all the work concerned withUsers,SitesandRoles. That would then have a dependency on those three repositories, and your controller would only have a dependency on the membership service.In response to your update: You could register the unit of work (i.e. the db context) as a "per web request" singleton - this is possible with Castle Windsor and many other DI frameworks. Then you can let your repositories depend on it and do all the changes, and let the controller depend on it for saving, and they will all get the same instance handed to them by the DI framework.