DI是实现面向切面和面向抽象的前提
DI越来越重要
DI就是依赖注入，现在来说，大部分框架都是以DI为基础组件的，每一个框架都有自己的DI组件，像dotnet core，java spring等，也都为自己的框架量身打造了DI工具。
面向对象的几个原则
- 依赖倒置原则（DIP）：一种软件架构设计的原则（抽象概念）。
- 控制反转（IoC）：一种反转流、依赖和接口的方式（DIP的具体实现方式）。
- 依赖注入（DI）：IoC的一种实现方式，用来反转依赖（IoC的具体实现方式）。
- IoC容器：依赖注入的框架，用来映射依赖，管理对象创建和生存周期（DI框架）。
DI的作用
在很多教程里，DI与IOC基本是相同的概念，其实DI是IOC的具体实现，而我们说的autofac,spring ioc,unity castle都是DI框架，也叫做ioc容器！它们的作用就是统一管理对象，这个管理也包括了对象的产生和销毁，产生就是new出一个对象，销毁就是对象的生命周期，一般来说根据生命周期的范围，可以分为瞬间（用完就销毁），单次http请求(请求结束后销毁）和单例（应用程序重启时销毁），我们根据对象的功能去定义它们，例如一个日志组件，它可以被定义为单例的；而一个仓储对象，它需要定义成'瞬间销毁'的。
DI在公用组件里的表现
公用组件，它可能是一个公用的架构，为了完成某个功能而被设计出来的稳定的框架，它内部的工作流程相对固定，而实现的具体细节可以由开发人员根据项目自定义，要想实现这种设计 ，我们就想到了面向抽象的设计，即面向接口的编程，组件里的对象都是抽象定义的，并且不负责生产对象，因为只要生命就是具体的，所以这里的对象都是需要通过DI产生的！
我们用到的太多框架都是这种设计，大家有时间 可以 看看它们的源代码：
- .net identity4
- .net abp
- java springboot
- java spring security
设计一个授权框架
Lind.Authorization概述
Lind.Authorization是一个授权架构体系，主不但有授权的核心逻辑，而且也是面向接口的体现，授权的核心逻辑是固定的，TokenAuthenticationFilter是一种业务场景的功能组件，它的主逻辑不能修改，但里面的每块内容可以根据项目自身去实现，这类型于模板方法模式，它规定的业务流程，开发人员根据具体业务去实现里面的细节。
Lind.Authorization组成
- IUserDetails授权实体接口，可能是用户表，账户表等
- IUserDetailsService授权实体业务接口，规定了授权时需要的方法，具体项目需要去实现它
- IUserDetailsAuthenticationProvider授权提供者接口，实现了基本的授权业务代码，具体项目可以覆盖它的方法
- TokenAuthenticationFilter基于token的授权过滤器，主要实现了对请求方法的拦截，它是授权的入口
- TokenUserDetailsAuthenticationProvider为token过滤器实现的授权管理者，提供一些公开的方法，使用者可以继承它，根据自己需要重写里面的方法
TokenAuthenticationFilter认证的过程
下面看一下授权组件的依赖关系：
TokenAuthentictokenationFilter
>
IUserDetailsAuthenticationProvider
>
IUserDetailsService
>
IUserDetails开发人员如果希望在自己项目中使用它，最少要实现这种个接口
IUserDetailsService：用户获取，token生成，token获取
IUserDetails：用户实体