面向接口編程
一般在實現一個系統的時候,通常是將定義與實現合為一體,不加分離的，我認為最為理解的系統設計規范應該是所有的定義與實現分離，盡管這對于系統中某些復雜的情況有些繁煩。
面向接口編程設計
使用面向接口編程思想將層與層之間通過接口依賴,下層不是直接給上層提供服務，而是定義一組接口供上層調用。至于具體的業務實現，是開發中需要做的事情，在項目架構階段，只需要定義好層與層之間的接口依賴,將框架搭建起來,編譯可以直接通過。
為什么要有面向接口編程設計？
為了提高架構的靈活性,降低層和層之間的依賴(耦合)
在一個系統框架中一個接口層可以根據不同的業務對應的有不同的實現層提供服務。
舉個例子 多層架構中,前后端分離的情況下前端只做一些弱邏輯處理，表現層只控制網絡請求的輸入輸出(通過IBLL接口和業務邏輯層依賴),業務邏輯層執行和處理強邏輯,對應不同的業務可以編寫不同的服務(IBLL接口 提供Bll.pc或者Bll.mobile多套服務)供表現層調用，
數據持久化層一般只做一些原子性的操作
數據持久化層大部分使用關系型數據庫,也有使用搜索引擎的還有文件系統,非關系型數據庫的
?
依賴倒置
在軟件設計原則中，有一種重要的思想叫做依賴倒置。它的核心思想是：不能讓高層組件依賴底層組件，而且，不管高層組件和底層組件，兩者都應依賴于抽象。
那么，這個原則和我們上面的原則是否矛盾呢？其實并不矛盾。
因為這個原則定義中的“依賴”是指“具體依賴”，而上面定義中的依賴全部指“抽象依賴”。我對這兩種依賴的定義如下：
具體依賴——如果P層中有一個或一個以上的地方實例化了Q層中某個具體類，則說P層具體依賴于Q層。
抽象依賴——如果P層沒有實例化Q層中的具體類，而是在一個或一個以上的地方實例化了Q層中某個接口，則說P層抽象依賴于Q層，也叫接口依賴于Q層。
依賴注入:
我們設計的分層架構，層與層之間應該是松散耦合的。因為是單向單一調用，所以，這里的“松散耦合”實際是指上層類不能具體依賴于下層類，而應該依賴于下層提供的一個接口。這樣，上層類不能直接實例化下層中的類，而只持有接口，至于接口所指變量最終究竟是哪一個類，則由依賴注入機制決定。
層次劃分：
目前，典型的分層架構是三層架構，即自底向上依次是數據訪問層、業務邏輯層和表示層。
職責劃分：
目前，在典型的三層架構中，對層次各自的職責劃分并沒有一個統一的規范，綜合現有的成功實踐和.NET平臺的特殊性，在本文中將三層架構的職責劃分如下：
數據訪問層——負責與數據源的交互，即數據的插入、刪除、修改以及從數據庫中讀出數據等操作。對數據的正確性和有效性不負責，對數據的用途不了解，不負擔任何業務邏輯。
業務邏輯層——負責系統領域業務的處理，負責邏輯性數據的生成、處理及轉換。對流入的邏輯性數據的正確性及有效性負責，對流出的邏輯性數據及用戶性數據不負責，對數據的呈現樣式不負責。
表示層——負責接收用戶的輸入、將輸出呈現給用戶以及訪問安全性驗證。對流入的數據的正確性和有效性負責，對呈現樣式負責，對流出的數據正確性不負責，但負責在數據不正確時給出相應的異常信息。
在一個系統框架中一個接口層可以根據不同的業務對應的有不同的實現層提供服務。
舉個例子 多層架構中,前后端分離的情況下前端只做一些弱邏輯處理，表現層只控制網絡請求的輸入輸出(通過IBLL接口和業務邏輯層依賴),業務邏輯層執行和處理強邏輯,對應不同的業務可以編寫不同的服務(IBLL接口 提供Bll.pc或者Bll.mobile多套服務)供表現層調用，
數據持久化層一般只做一些原子性的操作
數據持久化層大部分使用關系型數據庫,也有使用搜索引擎的還有文件系統,非關系型數據庫的
