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：用户实体