依赖注入解释

from:https://www.cnblogs.com/jesse2013/p/di-in-aspnetcore.html 

1.1依赖

比如我们在AccountController这个控制器需要完成和用户相关的注册、登录 等事情。其中的登录我们由EF结合Idnetity来完成，所以我们封装了一个EFLoginService。这里AccountController就有一个ILoginService的依赖。

当一个类需要另一个类协作来完成工作的时候就产生了依

这里有一个设计原则：依赖于抽象，而不是具体的实现。所以我们给EFLoginService定义了一个接口，抽象了LoginService的行为。

 

1.2 什么是注入

注入体现的是一个IOC（控制反转的的思想）。在反转之前 ，我们先看看正转。

 

AccountController自己来实例化需要的依赖。

1 2 3 4 5

private ILoginService<ApplicationUser> _loginService; public AccountController() {   _loginService = new EFLoginService() }

　　

大师说，这样不好。你不应该自己创建它，而是应该由你的调用者给你。于是你通过构造函数让外界把这两个依赖传给你。

1 2 3 4 5

public  AccountController(ILoginService<ApplicationUser> loginService) {   _loginService = loginService; }

　　

把依赖的创建丢给其它人，自己只负责使用，其它人丢给你依赖的这个过程理解为注入。

1.3 为什么要反转？

为了在业务变化的时候尽少改动代码可能造成的问题。

比如我们现在要把从EF中去验证登录改为从Redis去读，于是我们加了一个 RedisLoginService。这个时候我们只需要在原来注入的地方改一下就可以了。

1 2 3 4 5

public  AccountController(ILoginService<ApplicationUser> loginService) {   _loginService = loginService; }

　　

// 用Redis来替换原来的EF登录 var controller = new AccountController(new RedisLoginService()); controller.Login(userName, password);

1.4 何为容器

上面我们在使用AccountController的时候，我们自己通过代码创建了一个ILoggingServce的实例。想象一下，一个系统中如果有100个这样的地方，我们是不是要在100个地方做这样的事情？ 控制是反转了，依赖的创建也移交到了外部。现在的问题是依赖太多，我们需要一个地方统一管理系统中所有的依赖，容器诞生了。

 

容器负责两件事情：

• 绑定服务与实例之间的关系

• 获取实例，并对实例进行管理（创建与销毁）