軟體系統架構中的分層思想

標籤：http   使用   ar   資料   sp   問題   c   工作   ef   

軟體系統架構中的分層思想

關於分層結構

眾所周知，經典的三層結構包括資料訪問層、商務邏輯層和展示層。當然，如果繼續擴充下去，還可以分為4層、5層……

我相信很多人都用過，很多人都寫過，但是為什麼要這麼做，還是有一部分人是不能夠說清楚的，這不是我猜想的，而是遇見過很多想分層但是分的亂七八糟的階層。

1. 資料訪問層：

功能描述：處理與資料庫之間的互動，不應對資料做任何業務上的加工。捕獲資料庫互動式出現的異常，拋出或記錄下來。

說明：它的作用就是資料訪問，如果你沒有用其他的類似於ORM的架構，那麼這裡應該是SQL語句集合地（或者你可以把SQL語句寫在預存程序中），商務邏輯層和展示層絕對不能出現SQL語句（包括SQL的關鍵字，單引號、百分比符號、LIKE等都不能出現）。那麼如何組合動態SQL語句呢？這應該是最大的一個問題。我見過很多系統在商務邏輯層定義相當多的型參，然後在展示層收集參數資料，傳入商務邏輯層後拼合SQL語句，最後傳入資料訪問層執行操作，分層的概念已經完全沒有意義了。如何解決這個問題呢？最早的強型別資料集、自訂的業務實體，LINQ，或者ORM都可以解決，當然了，這隻是他們的一部分功能（其實，我不太願意用類似於NHibernate的HQL或LINQ）

2. 資料介面層：

功能描述：提供資料訪問層的介面標準、以便於提供多資料庫的支援，即資料庫的隨意遷移。

這裡我要提一下資料介面層，我見過有很多項目組在資料訪問層的上面加了一個資料介面層，然後資料訪問層是各個資料介面層的具體實現，但是在商務邏輯層執行個體化資料層的時候，仍然是執行個體化到具體的類對象。

IDal_MyClass dalmyclass = new DAL_SQLClass();

我不知道為什麼要這麼做，除了增加了工作量，其他的一點意義也沒有。

那麼到底需不需要這麼資料介面層呢？我認為在做一個支援多資料庫的系統（做產品會多見一些，比如一個CRM系統即可支援SQL Server，也支援Oracle和MySql）時就要用到資料介面層了，當然，單單一個資料介面層完成不了這個任務，你還要為每一種資料庫單獨做他們自己的資料訪問層，並且使用原廠模式以及依賴注入（比如Castle）技術就可以實現多資料庫的支援了，你可以在產品安裝或者運行時隨便進行資料庫間的遷移。

3. 商務邏輯層：

功能描述：接受從展示層傳過來的資料，做業務上的資料校正，並實現商務程序，最後，把加工後的資料傳給資料訪問層。

你可以認為在三層之間有兩堵牆，三層之間誰也看不見誰，我只做好我的本職工作，其他的事情我不關心。商務邏輯層應該是設計者最關注的地方，也是設計模式應用最廣泛的地方，商務邏輯層設計的關鍵就是盡量的實現松耦合，如果商務邏輯層中的各個類之間都有調用關係，那這就是一個很糟糕的設計。進一步來說，如果把這些松耦合的功能模組的介面作為一種服務的模式（比如Web Service）發布出去，OK，這就是SOA。

4. 業務外觀層：

功能描述：把鬆散的商務邏輯層內的各個細分功能在這裡整合，而後作為一個子系統的統一介面發布出去。這也是設計模式的一種。

業務外觀層應該是對商務邏輯層的進一步封裝。這隻有在商務邏輯功能十分繁多但彼此間又有聯絡的時候才會有用。我剛才說過了，商務邏輯層盡量要實現松耦合，但是各個業務之間肯定是有聯絡的啊，這種聯絡起來的工作就要交給業務外觀層。要把有聯絡的幾個商務邏輯組合為一個子系統，然後在業務外觀層中實現這種聯絡並發布出去。

我見過很多項目有業務外觀層，但業務外觀層的方法僅僅是對商務邏輯層一個方法的封裝。這樣做除了增加工作量，沒有任何好處，還不如直接調用商務邏輯層。

5. 展示層：

功能描述：從使用者控制項中取得資料或者從商務邏輯層取得資料後展現出來，不應對取得的資料做任何加工。

在這層要是出現SQL語句那就更不應該了。在WEB項目中，因為效率的原因，很多時候要在用戶端做一些必填項的驗證（其實這也是商務邏輯的一部分），但這是值得的。

知其然，還要知其所以然，分層是有好處的，程式的結構很清晰，便於除錯、便於擴充、也便於閱讀。

軟體系統架構中的分層思想