当太多依赖项注入服务或控制器时重构的策略

时间:2011-05-17 02:02:56

标签: asp.net-mvc dependency-injection refactoring

我有一个ASP.NET MVC 1应用程序,它使用NHibernate和Castle Windsor进行IoC。控制器注入了服务类,这些服务类处理应用程序所需的所有逻辑和操作。服务类注入了存储库。每个存储库处理单个对象。对象通过NH映射到DB表。我试图在服务和控制器之间保持一对一的关系,但是有些服务在多个控制器中使用。

问题是某些服务现在依赖于10-15个存储库。例如,系统具有开票组件,其中某些操作取决于用户,客户,工作单,工作单行项目,发票,发票行项目,税收等。

当涉及到依赖性过载时,人们用什么策略来有效地重构?我正在考虑将一个服务拆分为多个服务,并删除服务和控制器之间的一对一尝试。但随后控制器级别的依赖性将增加。在事先建议的情况下,可以将一个控制器拆分成多个控制器,但我不相信,除非您将视图分解为部分视图,否则这样做会完成?我意识到这是一个广泛的问题,但我更需要指导而不是确切的答案。随意提供类似重构的文章或示例的链接。

2 个答案:

答案 0 :(得分:14)

你应该refactor to Facade Services,这涉及在一个更粗粒度的服务层中滑动,以协调更细粒度的服务。目前,您的控制器正在进行太多细粒度的工作。

FWIW my book的第6章包含了这个过程的一个例子,它还涉及了一些心理练习,可以用来确定要分组的适当服务集群。

请记住,特定服务可以是多个群集的成员。这基本上只表明这是应用程序中的中心服务。

答案 1 :(得分:14)

您的存储库方法存在缺陷。您应该专注于根实体,而不是为应用程序中的每个实体类型设置存储库。选择一些作为应用程序中顶级实体的实体,并围绕它们构建存储库。例如。工作单行项可能不需要自己的存储库,因为没有工作单它们就不能独立存在。

您在设计中可能创建的另一件事是非常贫乏的域层。因此,您的实体几乎只是POCO对象,而所有业务逻辑都包含在您的服务层中。考虑将部分或大部分逻辑移入域中。