在 asp.net 核心中使用依赖注入而不是手动创建实例的原因

Question

各位，我正在学习 Asp.net 核心。我面临如何创建服务类型实例的选择。有一些代码是我在使用 WCF 时写的：

public class SomeService:ISomeService
{
    [WebInvoke(UriTemplate="action1")]
    public void DoSomething1() => new DBAccessBroker1().DoSomethingWithDB();

    [WebInvoke(UriTemplate="action2")]        
    public void DoSomething2() => new DBAccessBroker2().DoSomethingWithDB();
}

在上面的代码中，我在创建服务实例 SomeService 的同时创建了 DBAccessBroker 的实例。现在，在 Asp.net 核心中，可以使用依赖注入实现相同的功能，如下所示：

public class Startup
{
    ...
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddSingleton<DBAccessBroker1>();
        services.AddSingleton<DBAccessBroker2>();
        ...
    }
    ...
}
public class SomeController : Controller
{
     DBAccessBroker1 broker1=null;
     DBAccessBroker2 broker2=null;
     public SimeController(DBAccessBroker1 broker1,DBAccessBroker2 broker2)
     {
         this.broker1=broker1;
         this.broker2=broker2;
     }

     [HttpPost("action1")]
     public void DoSomething1()=>broker1.DoSomethingWithDB();

     [HttpPost("action2")]
     public void DoSomething2()=>broker2.DoSomethingWithDB();
}

很明显，手动创建实例比使用DI更简洁，因为不需要注册DI服务，也不需要像从空中来一样写一个奇怪的带参数的controller构造函数

另一方面，我相信让微软将 DI 纳入 Asp.Net Core 一定有好处。我想应该使用缓存或某种可重用机制等功能来实现 DI。但我没能找到一些文件来证实这一点。所以就想知道有没有圈内人或者了解比较深的人可以告诉我DI的基本原理。在我的案例中，我需要被说服使用 DI 而不是手动创建我的服务类型的实例。

Answer 1

使用 DI 在您的案例中至少有两个优点：

1) 您不应该关心应该传递给代理构造器的参数。您将收到随时可用的实例，而它的创建逻辑位于其他地方（Startup.cs 或自定义工厂）。

2) DI 可以在处理相同的用户请求期间为控制器和一些其他服务提供相同的代理实例，并为多个类处理其他请求（甚至同时）提供其他实例 - 如果您注册它们范围生命周期。

如果您不需要这些 "features" - 您可以创建代理 "manually"。

在 asp.net 核心中使用依赖注入而不是手动创建实例的原因

The reasons of creating instance using Dependency Injection rather than manually in asp.net core

dependency-injection

createinstance

asp.net-core