DI是实现面向切面和面向抽象的前提

发布时间:2019-03-29 22:00:15发布者:Mr.Zhang阅读(632)

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




本文转自博客园,原文地址:https://www.cnblogs.com/lori/p/10623248.html