当引入服务或控制器的依赖关系过大时，重构策略 [英] Strategy to refactor when too many dependencies injected into service or controller

问题描述

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

问题是一些服务现在有依赖在10-15个仓库。系统有一个发票组件，例如，某些操作取决于用户，客户，工单，工单订单项，发票，发票行项目，税收等。

在依赖过载方面，人们习惯用什么策略有效地重构？我正在考虑将一个服务分成许多服务，并删除服务和控制器之间的1对1尝试。但是随后的控制器级别的依赖将会增加。使用以前的建议，可以将一个控制器分成多个控制器，但是我不相信这样做，除非您将视图分解为部分视图？我意识到这是一个广泛的问题，但我更多地寻找指导而不是确切的答案。随意提供链接到文章或类似重构的例子。

解决方案

你应该重构到Facade Services ，这涉及到在一层更新粗粒度的服务中滑动，以协调细粒度的服务。目前，您的控制器正在做太多精细的工作。

FWIW第6章我的书包含了这个过程的一个例子，它还涉及到一些可以做的心理练习，以确定要分组的适当的服务集群。

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

I have an ASP.NET MVC 1 application that uses NHibernate and Castle Windsor for IoC. The controllers have service classes injected, and these service classes handle all the logic and actions required by the app. The service classes have repositories injected. Each repository handles a single object. Objects are mapped to DB table via NH. I have tried to keep a one to one relationship between services and controllers, but some services are used in more than one controller.

The problem is that some services now have dependencies on 10-15 repositories. The system has an invoicing component for example, where certain actions depend on users, customers, work orders, work order line items, invoices, invoice line items, taxes, etc.

What strategies do people used to refactor effectively when it comes to dependency overload? I'm thinking of splitting one service into many services and to remove the 1-to-1 attempt between services and controllers. But then dependencies at the controller level will increase. Splitting one controller into many controllers is possible with the prior suggestion, but I don't believe that's done unless you break views into partial views? I realize this is a broad question, but I'm more looking for guidance than exact answers. Feel free to provide links to articles or examples of similar refactoring.

解决方案

You should refactor to Facade Services, which involves sliding in a new layer of more coarse-grained services that orchestrate the finer-grained services. Currently your Controllers are doing too much fine-grained work.

FWIW chapter 6 of my book contains an example of this process and it also touches on some of the mental exercises you can do to identify the appropriate clusters of services to be grouped.

Keep in mind that a particular service can be a member of more than one cluster. That basically just indicates that this is a central service in the application.

这篇关于当引入服务或控制器的依赖关系过大时，重构策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！