当太多依赖项注入服务或控制器时的重构策略
我有一个 ASP.NET MVC 1 应用程序，它使用 NHibernate 和 Castle Windsor 进行 IoC。控制器注入了服务类，这些服务类处理应用程序所需的所有逻辑和操作。服务类已注入存储库。每个存储库处理一个对象。对象通过NH映射到DB表。我试图在服务和控制器之间保持一对一的关系，但有些服务在多个控制器中使用。
问题是一些服务现在依赖于 10-15 个存储库。例如，系统有一个发票组件，其中某些操作取决于用户、客户、工作订单、工作订单行项目、发票、发票行项目、税收等。
当涉及到依赖超载时，人们使用什么策略来有效重构？我正在考虑将一项服务拆分为许多服务，并消除服务和控制器之间的一对一尝试。但随后控制器级别的依赖性将会增加。根据先前的建议，可以将一个控制器拆分为多个控制器，但我不认为这是可以完成的，除非您将视图分解为部分视图？我意识到这是一个广泛的问题，但我更寻求指导而不是确切的答案。请随意提供类似重构的文章或示例的链接。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您应该重构外观服务，这涉及滑入一个新的层更粗粒度的服务编排更细粒度的服务。目前您的控制器正在做太多细粒度的工作。
我的书的 FWIW 第 6 章包含此过程的示例，它还涉及您可以进行一些心理练习来确定要分组的适当服务集群。
请记住，一项特定服务可以是多个集群的成员。这基本上只是表明这是应用程序中的核心服务。
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.
您的存储库方法有缺陷。您应该关注根实体，而不是为应用程序中的每个实体类型建立一个存储库。选择一些应用程序中顶级实体的实体，并围绕它们构建存储库。 EG 工作订单行项目可能不需要自己的存储库，因为如果没有工作订单，它们就无法独立存在。
您可能在设计中创建的另一件事是一个非常贫乏的域层。因此，您的实体几乎只是 POCO 对象，而所有业务逻辑都包含在您的服务层中。考虑将部分或大部分逻辑移至域中。
Your repository approach is flawed. Instead of having a repository for each and every entity type in your application, you should focus on your root entities. Pick a few entities that are the top level entities in your application and build your repositories around them. E.G. work order line items likely don't need their own repository, as they can't exist on their own without a work order.
Another thing you've likely created in your design is a very anemic domain layer. So your entities are pretty much just POCO objects, while all of the business logic is contained in your service layer. Consider moving some or most of that logic into the domain.