從需求談起
我們舉個小例子來理解一般的方式與多層的方式有何不同假設:我需要顯示最近三個月內,所有營業員的銷售金額成績排名
一般的做法:
在一個畫面中,拉個GridView,一個SqlDataSouce,把需求的語法設定好在SqlDataSouce之後,接著顯示出來就可以了。這樣的做法,從【資料的展現】【商業邏輯的條件設定】【資料庫的存取】都在一個畫面中處理完畢。
這樣的做法,可以說把所有的東西通通寫在畫面的程式裡面。但是如果哪天想到,我的介面想改成Windows Form、WPF'、SilverLight、PDA去呈現,那麼我們一且都必須重新寫過
分層做法:
如果我們把介面抽離出來,例如使用元件負責處理【商業邏輯條件設定】與【資料的存取】,那麼就會變成如下此時介面的部分只是負責畫面的呈現,他的資料來源是從中間的元件而來,這樣未來如果想改介面為其他的方式(Windows Form、WPF'、SilverLight、PDA),那麼中間的部分就可不必重寫,只需把介面重寫後再與元件結合
進一步的切分(商業邏輯層、資料存取層)
假設本來的系統,資料的架構比較小、量也不大,因此開發初期使用Access作為資料庫,而當架構變大了,資料變多了,想要用MS SQL Server來處理資料,那麼我們可以很慶幸的,介面層的部分可以不用更動。但是中間層可能有很多的語法、很多的資料存取有所不同了,因此將需要大幅的改寫中間層的程式。但是如果,我們將【商業邏輯條件】與【資料存取動作】在切分開來,那麼中間層的邏輯條件判斷將不須變更,只需將資料存取的部分做改寫。這樣的架構將變成如下。這樣的架構下,未來資料庫就可以變更而不動到商業邏輯層,只需改寫資料存取層。因此在多層架構中,就會區分為【介面層】、【商業邏輯層】、【資料存取層】這三層,一般成之為【三層架構(3 Tier)】。那又何來的多層呢??在較為大型的系統中,可能區分為各個不同的部分(例如:製造、管理、庫存、銷售、物流、服務維修、…)等。因此中間層可能依照各個不同的屬性,各自獨立在不同的程式中,我們把每個部分設定為一個層的話,這些層式對等的,但是有些時候又需要互相協調合作,此時就可能出現多層的架構,例如:銷售時,須檢查庫存,維護庫存,接著要產生物流的送貨如下圖,因此區分出來的商業邏輯層,不只可以獨立的運作,也可以與其他的商業邏輯層協同運作,形成多層架構。
實踐多層架構的幾個方式
虛擬分層與實體分層
虛擬分層:
所謂的虛擬分層,是指【介面層】、【商業邏輯層】、【資料存取層】在相同的主機上運作,是邏輯上的分層。由於都在相同的主機上運作,所以架構上單純許多,可以透過類別(Class)來撰寫【商業邏輯層】與【資料存取層】
實體分層:
而實體的分層,就可能這三層分別在不同的主機上,甚至商業邏輯層可能有多部的主機,分別處理各自的商業邏輯(例如:製造、管理、庫存、銷售、物流、服務維修、…都有各自的主機)在如何實踐上,實體分層就複雜多了,由於主機不同,彼此又要協調合作,變成要處理【分散式交易】。目前小喵所知,可以透過【COM+】、【WCF】來實現這的架構
沒有留言:
張貼留言