Question

我读过这篇文章：http://peterspattern.com/dependency-injection-and-class-inheritance/（很棒的文章顺便说一句）

现在，我有一个ASP.NET Core Web应用程序，我正在考虑将所有服务放在另一个类中，并使用内置的DI来解决这个问题。我想这样做的唯一原因是，每次需要向某个类添加新服务时，不必手动更新每个构造函数。

例如，而不是：

public class Foo {
IServiceOne _serviceOne;
IServiceTwo _serviceTwo;

 public Foo(IServiceOne serviceOne, IServiceTwo serviceTwo) {
   _serviceOne = serviceOne;
   _serviceTwo = serviceTwo;
 }
}

我可以这样做：

public interface IMyServices {
  IServiceOne ServiceOne {get;}
  IServiceTwo ServiceTwo {get;}
 }

public class Foo {
   IServiceOne _serviceOne;
   IServiceTwo _serviceTwo;

    public Foo(IMyService services) {
      _serviceOne = services.ServiceOne;
      _serviceTwo = services.ServiceTwo; 
    }
}

编辑:(我已经离开了一些部分，比如实现IMyService的类和在Startup.cs中注册服务）

现在，我正在处理的应用程序非常庞大，包含所有服务的类可能包含20-30个服务。

我的问题是：这是个好主意吗？我关心的是表现。即使不需要，所有构造函数中的所有服务都会传递，这感觉就像一个坏主意。但如果只有一个类可以使用新服务进行更新，那么它将为我们节省大量时间，然后该服务在所有类中都可用。

在实际请求时，是否有延迟加载服务，或默认情况下是否完成？

Answer 1

哇，您链接的那篇文章将现实世界的问题与不同的问题（constructor over-injection）的解决方案相结合。它没有解决原始问题，即using inheritance for a Controller in the first place。

真的很臭必须将相同的服务注入所有控制器。这将问题完全置于crosscutting concerns。

的上下文中

正如我之前提到的in this answer，有几种方法可以解决这个问题，.NET Core中最好的方法是filters和middleware。

我认为继承也是一种选择，但它显然是最差的，因为它将不可避免地导致创建god object。

注意：我并不是说继承在某些情况下没有价值，但控制器通常不是这种情况之一。

依赖注入ASP.NET核心

1 个答案: