依賴注入是什麼意思？前端
依賴倒置
在軟件設計原則中，有一種重要的思想叫作依賴倒置。它的核心思想是：不能讓高層組件依賴底層組件，並且，無論高層組件和底層組件，二者都應依賴於抽象。
那麼，這個原則和咱們上面的原則是否矛盾呢？其實並不矛盾。
由於這個原則定義中的「依賴」是指「具體依賴」，而上面定義中的依賴所有指「抽象依賴」。我對這兩種依賴的定義以下：數據庫
具體依賴——若是P層中有一個或一個以上的地方實例化了Q層中某個具體類，則說P層具體依賴於Q層。後端
抽象依賴——若是P層沒有實例化Q層中的具體類，而是在一個或一個以上的地方實例化了Q層中某個接口，則說P層抽象依賴於Q層，也叫接口依賴於Q層。
依賴注入:
咱們設計的分層架構，層與層之間應該是鬆散耦合的。由於是單向單一調用，因此，這裏的「鬆散耦合」實際是指上層類不能具體依賴於下層類，而應該依賴於下層提供的一個接口。這樣，上層類不能直接實例化下層中的類，而只持有接口，至於接口所指變量最終到底是哪個類，則由依賴注入機制決定。
層次劃分：
目前，典型的分層架構是三層架構，即自底向上依次是數據訪問層、業務邏輯層和表示層。安全
職責劃分：
目前，在典型的三層架構中，對層次各自的職責劃分並無一個統一的規範，綜合現有的成功實踐和.NET平臺的特殊性，在本文中將三層架構的職責劃分以下：網絡
數據訪問層——負責與數據源的交互，即數據的插入、刪除、修改以及從數據庫中讀出數據等操做。對數據的正確性和有效性不負責，對數據的用途不瞭解，不負擔任何業務邏輯。架構
業務邏輯層——負責系統領域業務的處理，負責邏輯性數據的生成、處理及轉換。對流入的邏輯性數據的正確性及有效性負責，對流出的邏輯性數據及用戶性數據不負責，對數據的呈現樣式不負責。框架
表示層——負責接收用戶的輸入、將輸出呈現給用戶以及訪問安全性驗證。對流入的數據的正確性和有效性負責，對呈現樣式負責，對流出的數據正確性不負責，但負責在數據不正確時給出相應的異常信息。
在一個系統框架中一個接口層能夠根據不一樣的業務對應的有不一樣的實現層提供服務。
舉個例子 多層架構中,先後端分離的狀況下前端只作一些弱邏輯處理，表現層只控制網絡請求的輸入輸出(經過IBLL接口和業務邏輯層依賴),業務邏輯層執行和處理強邏輯,對應不一樣的業務能夠編寫不一樣的服務(IBLL接口 提供Bll.pc或者Bll.mobile多套服務)供表現層調用，
數據持久化層通常只作一些原子性的操做
數據持久化層大部分使用關係型數據庫,也有使用搜索引擎的還有文件系統,非關係型數據庫的
前後端分離