0

伙计们，我正在学习 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 Core 中，可以使用依赖注入实现相同的功能，如下所示：

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 服务并编写一个奇怪的带参数的控制器构造函数，就像从空中来的一样。

另一方面，我相信让微软将 DI 整合到 Asp.Net Core 中一定有好处。我想 DI 应该使用缓存或可重用机制之类的功能来实现。但我没能找到一些文件来确认。所以我想知道是否有一些内部人士或了解更深的人可以告诉我 DI 的基本原理。我需要被说服使用 DI 而不是手动创建我的服务类型的实例。

4

1 回答 1

2

在您的情况下，使用 DI 至少有两个优点：

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

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

如果您不需要任何这些“功能” - 您可以“手动”创建代理。

于 2017-06-15T14:12:52.790 回答