查看我的Controller(我使用依赖注入来管理依赖项):
public RoleController(IRoleRepository roleRepository, ISiteRepository siteRepository, IUserRepository userRepository, IDbContext dbContext)
{
_roleRepository = roleRepository;
_siteRepository = siteRepository;
_userRepository = userRepository;
_dbContext = dbContext;
}
拥有一个具有许多依赖关系的类是代码味道?正确?
但是,在我的示例中,我需要将Users
和Sites
关联到Role
,然后我需要这些依赖关系来进行此关联。
邮件列表上的一些人我被告知有太多的依赖关系表明某些事情可能是错误的。但我没有别的办法。我分开了我的责任,在那种情况下有一些我不知道如何对待?有什么不对吗?
更新
我需要Repositories和DbContext,因为DbContext是我的UnitOfWork,存储库不保存。
此示例是一个简单的CRUD,其中包含一些其他功能,例如视图中的关联和GRID。
更新2:
我正在使用我的UI层是MVC的架构。
答案 0 :(得分:8)
我认为这不是一件坏事,因为你用一个好的DI框架管理依赖关系(即不使用poor man's DI)。这样,你明确地说控制器将需要所有这些东西,因为它会。 (请注意,在应用程序的许多其他部分中,这可能不是一个有效的参数 - 控制器在控制和指导程序流的方式上是特殊的,因此有一个自然的解释为什么它需要看到很多应用程序的一部分......)
但是,如果你真的想在这种特定情况下限制依赖项的数量,那么创建一个MembershipService
是有意义的,它会完成与Users
,{{1}有关的所有工作。 }和Sites
。那将依赖于这三个存储库,并且您的控制器将只依赖于成员资格服务。
响应您的更新:您可以将工作单元(即数据库上下文)注册为“每个Web请求”单例 - 这可以通过Castle Windsor和许多其他DI框架实现。然后你可以让你的存储库依赖它并进行所有的更改,让控制器依赖它来保存,并且它们都将获得由DI框架传递给它们的相同实例。