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是一個授權架構體系，主不但有授權的核心邏輯，而且也是面向介面的體現，授權的核心邏輯是固定的，TokenAuthenticationFilter是一種業務場景的功能元件，它的主邏輯不能修改，但裡面的每塊內容可以根據專案自身去實現，這型別於模板方法樣式，它規定的業務流程，開發人員根據具體業務去實現裡面的細節。

Lind.Authorization組成

• IUserDetails授權物體介面，可能是使用者表，賬戶表等
• IUserDetailsService授權物體業務介面，規定了授權時需要的方法，具體專案需要去實現它
• IUserDetailsAuthenticationProvider授權提供者介面，實現了基本的授權業務程式碼，具體專案可以改寫它的方法
• TokenAuthenticationFilter基於token的授權過濾器，主要實現了對請求方法的攔截，它是授權的入口
• TokenUserDetailsAuthenticationProvider為token過濾器實現的授權管理者，提供一些公開的方法，使用者可以繼承它，根據自己需要重寫裡面的方法

TokenAuthenticationFilter認證的過程

下麵看一下授權元件的依賴關係：

TokenAuthentictokenationFilter
>
IUserDetailsAuthenticationProvider
>
IUserDetailsService
>
IUserDetails

開發人員如果希望在自己專案中使用它，最少要實現這種個介面

IUserDetailsService：使用者獲取，token生成，token獲取
IUserDetails：使用者物體