【ASP.NET Core 基础知识】--依赖注入（DI）--在ASP.NET Core中使用依赖注入

一、在ASP.NET Core中实现依赖注入

1.1 配置依赖注入

在ASP.NET Core中实现依赖注入的第一步是配置依赖注入。ASP.NET Core使用了一个称为依赖注入容器（DI Container）的组件来管理对象之间的依赖关系。DI容器在应用程序启动时被配置，并且可以在应用程序的整个生命周期内使用。以下是配置依赖注入的基本步骤：

1. 注册服务：
   • 使用services.AddTransient<TService>()来注册一个瞬态服务，每次请求都会创建一个新的实例。
   • 使用services.AddScoped<TService>()来注册一个作用域服务，每次请求会创建一个实例，但在同一个Http请求的生命周期内共享同一个实例。
   • 使用services.AddSingleton<TService>()来注册一个单例服务，只会创建一个实例，并在应用程序的整个生命周期内共享。

   这些方法通常在ConfigureServices方法中调用，该方法在Startup类中定义。

2. 使用IServiceProvider：
   • 在需要注入服务的地方（例如控制器、服务、视图等），通过构造函数或属性注入来使用服务。
   • 在控制器中，可以使用HttpContext.RequestServices属性获取IServiceProvider实例，并通过它来获取服务。
3. 配置中间件：
   • 在Configure方法中，使用依赖注入来构造中间件实例。
   • 中间件通常需要注入服务，因此中间件应该使用构造函数注入。
4. 使用DI容器的其他功能：
   • ASP.NET Core的DI容器提供了更多的功能，例如支持自动解析服务、使用元数据等。

下面是一个简单的示例，演示如何配置依赖注入：

代码语言：javascript复制

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        // 注册瞬态服务
        services.AddTransient<IMyService, MyService>();
        
        // 注册作用域服务
        services.AddScoped<IHttpContextAccessor, HttpContextAccessor>();
        
        // 注册单例服务
        services.AddSingleton<ISomeOtherService, SomeOtherService>();
    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        // 使用注入的服务构造中间件
        app.UseMiddleware<MyMiddleware>();
        
        // ...
    }
}

Tip：在ASP.NET Core 3.0之前，使用Configure方法来配置依赖注入。在ASP.NET Core 3.0及更高版本中，推荐使用AddServices方法。

在配置完依赖注入后，服务就可以在应用程序的任何地方使用，只要它们被正确的注入到需要的类中。

1.2 定义服务

在ASP.NET Core中实现依赖注入的第二步是定义服务。服务是应用程序中需要注入到其他组件的对象或类。服务可以是瞬态、作用域或单例的，这取决于它们是如何注册的。以下是定义服务的步骤：

1. 创建服务类：
   • 创建一个类，它实现了某个接口或继承自某个基类。这个类就是你的服务类，它包含了实现逻辑。
   • 如果服务类没有对应的接口或基类，也可以直接创建一个类，但最好还是提供一个接口或基类以支持依赖注入的灵活性。
2. 定义接口或基类：
   • 如果你创建了一个服务类，那么应该为它定义一个接口或基类，以便其他组件可以依赖注入这个服务。
   • 接口或基类定义了服务的公共行为，而具体的实现则由服务类来完成。
3. 注册服务：
   • 在ConfigureServices方法中，使用AddTransient、AddScoped或AddSingleton方法注册服务。
   • 注册时应该传入一个工厂方法或使用默认的工厂方法来创建服务实例。

以下是一个简单的示例，演示如何定义服务并注册到DI容器中：

代码语言：javascript复制

// 定义服务接口
public interface IMyService
{
    void DoSomething();
}

// 定义服务实现
public class MyService : IMyService
{
    public void DoSomething()
    {
        // 实现逻辑
    }
}

// 在Startup.cs中注册服务
public void ConfigureServices(IServiceCollection services)
{
    // 注册瞬态服务
    services.AddTransient<IMyService, MyService>();
    
    // 注册作用域服务
    services.AddScoped<IHttpContextAccessor, HttpContextAccessor>();
    
    // 注册单例服务
    services.AddSingleton<ISomeOtherService, SomeOtherService>();
}

在这个例子中，MyService类实现了IMyService接口，并在ConfigureServices方法中被注册为瞬态服务。这意味着每次需要注入IMyService时，DI容器都会创建一个新的MyService实例。 定义好服务和注册到DI容器后，服务就可以被注入到其他组件中，如控制器、视图组件、中间件等。

1.3 使用服务

在ASP.NET Core中，一旦服务被定义并注册到DI容器中，你就可以在需要的地方使用这些服务。以下是使用服务的一些常见方法：

构造函数注入：

通过在组件的构造函数中标记需要注入的服务，让DI容器自动注入服务。

例如，如果你有一个服务类MyService，你可以在控制器或服务中通过构造函数注入该服务：

代码语言：javascript复制

public class MyController : Controller
{
    private readonly IMyService _myService;

    public MyController(IMyService myService)
    {
        _myService = myService;
    }
}

属性注入：

除了构造函数注入，你还可以使用属性注入。在组件中定义一个带有[FromInject]注解的属性，DI容器会自动将服务注入到该属性中。

例如：

代码语言：javascript复制

public class MyService
{
    private readonly IMyService _myService;

    public MyService([FromInject] IMyService myService)
    {
        _myService = myService;
    }
}

方法注入：

在某些情况下，你可能希望在方法级别注入服务。你可以使用HttpContext.RequestServices来获取IServiceProvider实例，然后通过它来获取服务。

例如：

代码语言：javascript复制

public class MyController : Controller
{
    public IActionResult MyAction()
    {
        var myService = HttpContext.RequestServices.GetService<IMyService>();
        // 使用myService
        return View();
    }
}

视图注入：

在视图中，你可以使用@inject关键字来注入服务。

例如：

代码语言：javascript复制

@model MyModel
@inject IMyService MyService
<!-- 使用MyService -->

中间件注入：

在中间件中，你可以通过构造函数或属性注入来使用服务。

例如：

代码语言：javascript复制

public class MyMiddleware
{

    private readonly IMyService _myService;

    public MyMiddleware(IMyService myService)
    {
        _myService = myService;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        // 使用_myService
        await next.Invoke();
    }
}

Tip：注入服务时应根据具体情况选择最合适的方法。在某些情况下，构造函数注入可能更适合，因为它可以确保依赖项在对象创建时就被提供。在其他情况下，属性注入或方法注入可能更方便。

二、ASP.NET Core中的依赖注入核心对象

2.1 解析Startup对象

在ASP.NET Core中，依赖注入（DI）的核心对象是IServiceProvider，它提供了对已注册服务的解析。Startup对象是应用程序启动时的重要对象，它的主要职责是配置服务和中间件。解析Startup对象实际上意味着解析由IServiceProvider提供的IServiceProvider实例，以便在应用程序启动过程中使用依赖注入。

1. 创建HostBuilder：
   • 使用Microsoft.AspNetCore.Hosting命名空间中的HostBuilder类来创建一个IHostBuilder实例。
   • 使用ConfigureServices方法注册服务和中间件。
2. 构建Host：
   • 通过调用HostBuilder的Build方法创建一个IHost实例。
   • 这个IHost实例包含了DI容器和应用程序的服务。
3. 运行Host：
   • 调用IHost的Run方法来启动应用程序。
   • 或者，调用IHost的RunAsync方法来启动应用程序并允许异步操作。
4. 使用DI：
   • 在应用程序的任何地方，都可以使用IServiceProvider来解析服务。
   • 例如，在控制器或服务中通过构造函数或属性注入来使用服务。

下面是一个简单的示例，演示如何使用Startup对象来配置服务和中间件，并解析服务：

代码语言：javascript复制

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

class Program
{
    static void Main(string[] args)
    {
        Host.CreateDefaultBuilder()
            .ConfigureServices(services =>
            {
                // 注册服务
                services.AddTransient<IMyService, MyService>();
                // 注册其他服务...
            })
            .Build()
            .Run(); // 运行应用程序
    }
}

class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        // 配置服务
    }

    public void Configure(IApplicationBuilder app)
    {

        // 配置中间件
    }
}

class MyService : IMyService
{
    private readonly IServiceProvider _serviceProvider;

    public MyService(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    // 使用解析的服务
}

在这个示例中，Startup类定义了ConfigureServices方法，用于注册服务，以及Configure方法，用于配置请求管道的中间件。在应用程序启动时，IServiceProvider会自动创建，并且可以在需要的地方使用，比如在MyService类的构造函数中。

Tip：IServiceProvider是解析服务的关键，它提供了对DI容器的访问，允许你在应用程序的任何地方获取已注册的服务。

2.2 解析中间件对象

在ASP.NET Core中，中间件对象是通过Use方法来解析和添加到请求管道中的。每个中间件都是一个处理请求和生成响应的函数。解析中间件对象通常发生在以下场景：

• 在Startup.Configure方法中：这是添加和配置中间件的标准位置。
• 在自定义中间件中：如果你创建了一个自定义中间件，你可能需要在其他地方解析该中间件对象。

以下是一个简单的示例，演示如何解析和使用中间件：

代码语言：javascript复制

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

class Program
{
    static void Main(string[] args)
    {
        Host.CreateDefaultBuilder()
            .ConfigureServices(services =>
            {
                // 注册中间件
                services.AddTransient<MyMiddleware>();
                services.AddRouting(); // 示例：添加路由中间件
                // 注册其他服务...
            })
            .Build()
            .Run(); // 运行应用程序
    }
}

class Startup
{
    public void Configure(IApplicationBuilder app)
    {
        // 使用中间件
        app.UseMyMiddleware();
        app.UseRouting(); // 使用路由中间件
        // 使用其他中间件...
    }
}

class MyMiddleware
{
    private readonly RequestDelegate _next;

    public MyMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        // 在这里处理请求

        // 调用管道中的下一个中间件
        await _next(context);
    }
}

在这个例子中：

1. MyMiddleware是一个自定义中间件类，它实现了InvokeAsync方法来处理请求，并通过RequestDelegate类型的参数来调用管道中的下一个中间件。
2. 在Startup.Configure方法中，我们使用app.UseMyMiddleware()来添加和配置MyMiddleware中间件。
3. 中间件的解析是通过DI容器自动完成的，当我们在ConfigureServices方法中添加services.AddTransient<MyMiddleware>()时。
4. 每个中间件都会在前一个中间件完成处理后调用，从而形成了一个请求处理管道。

Tip：中间件的解析和添加是由ASP.NET Core框架自动处理的，开发人员通常不需要直接解析中间件对象，而是使用Use方法来添加它们到请求管道中。

2.3 解析Controller对象和View对象

在ASP.NET Core中，依赖注入允许我们轻松地将服务（例如Controller和View）注入到需要它们的组件中。ASP.NET Core的依赖注入框架基于.NET Core的DI框架，提供了几个核心对象来管理和解析依赖关系。

1. 解析Controller对象：
   • Controller对象是MVC框架的一部分，它们处理HTTP请求并准备响应。
   • 控制器通常作为服务注册到DI容器中，并通过构造函数注入的方式解析。

解析Controller对象的示例代码如下：

代码语言：javascript复制

using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.DependencyInjection;

public class MyController : ControllerBase
{
    private readonly IMyService _myService;

    public MyController(IMyService myService)
    {
        _myService = myService;
    }

    [HttpGet]
    public async Task<IActionResult> GetData()
    {
        // 使用注入的服务
        var data = await _myService.GetData();
        return Ok(data);
    }
}

// 在Startup.cs的ConfigureServices方法中注册服务
public void ConfigureServices(IServiceCollection services)
{
    services.AddTransient<IMyService, MyService>();
    services.AddTransient<MyController>();
}

在上面的代码中，MyController通过构造函数注入了一个IMyService类型的服务实例。在Startup.cs的ConfigureServices方法中，我们注册了MyService和MyController作为瞬态服务。 2. 解析View对象：

• View对象是MVC视图引擎的一部分，它们用于生成HTML响应。
• 视图通常通过Razor模板创建，并在控制器中返回给客户端。

解析View对象的示例代码如下：

代码语言：javascript复制

using Microsoft.AspNetCore.Mvc;

public class HomeController : Controller
{
    public IActionResult Index()
    {
        return View();
    }
}

在上面的代码中，HomeController的Index方法返回了一个视图。ASP.NET Core会自动查找与控制器方法名称匹配的Razor视图，并使用它来生成HTML响应。

Tip：视图本身不是一个DI对象，但控制器可以使用DI容器解析服务，并将这些服务传递给视图使用。例如，可以在控制器中注入服务，并将服务传递给视图中的ViewModel，然后在视图中使用这些服务。

代码语言：javascript复制

public class HomeController : Controller
{
    private readonly IMyService _myService;

    public HomeController(IMyService myService)
    {
        _myService = myService;
    }

    public IActionResult Index()
    {
        var viewModel = new MyViewModel(_myService.GetData());
        return View(viewModel);
    }
}

在这个例子中，我们注入了一个IMyService服务，并在视图的ViewModel中使用了这个服务。

三、依赖注入的最佳实践

3.1 服务定位器模式

服务定位器模式（Service Locator Pattern）在依赖注入（DI）中是一个有争议的模式。虽然它可以提供一些灵活性，但过度使用服务定位器模式可能导致以下问题：

1. 耦合性增加：使用服务定位器模式可能会增加组件之间的耦合性，因为它们不是直接解析依赖项，而是通过一个中心化的服务来获取依赖项。
2. 依赖反转原则的违反：依赖反转原则（DIP）建议高级模块不应该依赖于低级模块，而是应该依赖于抽象。服务定位器模式可能会违反这一原则，因为它可能导致组件直接依赖于具体的服务实现。
3. 测试困难：使用服务定位器模式可能会使得单元测试更加困难，因为难以模拟和替换通过服务定位器获取的服务。
4. 难以进行依赖管理：服务定位器模式可能导致难以跟踪应用程序中到底有哪些服务被使用，从而使得依赖管理变得复杂。

尽管有这些潜在问题，服务定位器模式在某些情况下仍然是一个有用的工具。例如，在需要动态地解析服务或者在某些服务只能由服务定位器本身提供的情况下，服务定位器模式可能是合适的。 最佳实践是尽量避免使用服务定位器模式，除非确实有必要。在需要使用服务定位器模式时，应该遵循以下建议：

• 限制使用范围：只在确实需要动态解析服务或者服务只能由服务定位器提供时使用该模式。
• 使用抽象：确保服务定位器返回的是抽象类型，而不是具体实现，以保持松耦合。
• 使用依赖注入容器：如果可能，使用DI容器提供的API来获取服务，而不是直接调用服务定位器的解析方法。
• 提供清晰的文档：如果使用了服务定位器模式，确保文档清晰地说明为什么需要这样做，以及如何使用。
• 避免滥用：避免在整个代码库中滥用服务定位器模式，这可能导致代码难以维护和测试。

Tip：服务定位器模式应作为最后的手段，而不是首选方法。

3.2 控制反转(IOC)

控制反转（Inversion of Control, IoC）是一种设计原则，其主要目的是降低代码之间的耦合度。在依赖注入（DI）中，控制反转通常指的是将对象创建和管理的工作从应用程序代码中移除，转而由外部容器（如ASP.NET Core内置的DI容器）来完成。以下是一些关于控制反转的最佳实践：

1. 明确依赖：在编写代码时，要明确声明依赖关系，这有助于提高代码的可读性和可维护性。
2. 使用构造函数注入：通过构造函数注入来满足依赖关系，这有助于确保依赖项在对象创建时就被正确地初始化。
3. 利用依赖注入容器：使用DI容器来自动管理对象的创建和依赖关系，这可以减少手动创建对象的工作，并且有助于确保依赖项正确地被解析。
4. 避免静态依赖：避免在代码中使用静态依赖关系，因为这会违反控制反转的原则，导致代码高度耦合。
5. 使用抽象：依赖注入通常与面向接口编程（Interface-Oriented Programming）相结合，这有助于确保低耦合和高度可测试性。
6. 延迟加载：在需要时才解析依赖项，这有助于减少不必要的内存使用。
7. 遵循依赖规则：确保依赖关系遵循依赖倒置原则（Dependence Inversion Principle, DIP），即高层模块不应该依赖于低层模块，应该依赖于抽象。
8. 使用服务定位器作为最后手段：在某些情况下，服务定位器模式可能是必要的，但要谨慎使用，并确保遵循上述最佳实践。
9. 编写可测试的代码：使用控制反转和依赖注入可以编写更容易测试的代码，因为代码的依赖关系可以更容易地被模拟和替换。
10. 保持简洁：不要为了使用控制反转和依赖注入而引入不必要的复杂性。在简单的情况下，直接的依赖可能更为合适。

在ASP.NET Core中，可以通过在Startup.cs的ConfigureServices方法中注册服务来实践控制反转，然后在需要这些服务的类中通过构造函数注入来使用它们。这种方法有助于保持代码的可维护性和可扩展性。

3.3 依赖注入的性能考虑

在考虑依赖注入（DI）的性能时，有几个方面需要注意：

1. 框架的选择：不同的DI框架和库在性能上可能会有所差异。选择性能高效的框架可以减少性能开销。
2. 容器解析性能：DI容器在解析依赖关系时可能会产生一些开销。在性能关键型应用中，可以考虑减少对容器的频繁调用，或者使用性能优化过的DI库。
3. 对象生命周期：尽量使用瞬态对象（每次请求创建新实例）来减少容器在解析依赖时的负担，特别是对于那些不需要长时间存在的对象。
4. 懒加载：对于非必需提前创建的对象，可以使用懒加载策略，这样只有在第一次使用时才会创建对象。
5. 性能测试：在实际应用中，对DI框架的性能进行基准测试，以确保选用的方案能够满足性能要求。
6. 缓存：对于需要频繁创建的对象，可以考虑使用缓存来减少对象的创建次数，从而提高性能。
7. 对象池：在某些场景下，可以使用对象池技术来重复利用已创建的对象，减少对象的创建和销毁开销。
8. 优化配置：根据应用的特点调整DI容器的配置，例如，通过限制注册的服务数量来提高性能。
9. 避免不必要的依赖：减少不必要的依赖关系可以降低DI容器的负担，提高解析性能。
10. 使用异步和多线程：在可能的情况下，使用异步和多线程技术来优化性能，特别是在长时间运行的任务中。

四、总结

今天我们学习了依赖注入（DI）的基本概念和最佳实践，包括控制反转（IoC）、构造函数注入、避免静态依赖等。同时，我们也了解了依赖注入的性能考虑，如使用瞬态对象、懒加载、对象池等技术来优化性能。在ASP.NET Core中，DI框架可以帮助我们轻松实现依赖注入，提高代码的可维护性和可扩展性。

core 对象 服务 依赖注入 asp

0 人点赞