基于.NET平臺的分層架構(gòu)實戰(zhàn)(三)架構(gòu)概要設(shè)計_.Net教程

推薦：基于.NET平臺的分層架構(gòu)實戰(zhàn)(二)需求分析與數(shù)據(jù)庫設(shè)計
在實際的項目中，需求分析和數(shù)據(jù)庫的設(shè)計是很重要的一個環(huán)節(jié)，這個環(huán)節(jié)會直接影響項目的開發(fā)過程和質(zhì)量。實際中，這個環(huán)節(jié)不但需要系統(tǒng)分析師、軟件工程師等計算機(jī)方面的專家，還需要相關(guān)領(lǐng)域的

本文主要是對將要實現(xiàn)的架構(gòu)進(jìn)行一個總體的描述，使朋友們對這個架構(gòu)有個宏觀上的認(rèn)識。這篇文章理論性的東西會偏多一點，從下篇開始，將進(jìn)行實際項目的開發(fā)。這篇文章的許多內(nèi)容摘自我的畢業(yè)論文。

架構(gòu)基本原則：

這里，將描述一些在這個架構(gòu)設(shè)計中的基本原則，其中很多都是經(jīng)典的設(shè)計原則，不過針對分層架構(gòu)的特點，用我自己的語言進(jìn)行了描述。其中也有我自己提出的原則。

逐層調(diào)用原則及單向調(diào)用原則

現(xiàn)在約定將N層架構(gòu)的各層依次編號為1、2、…、K、…、N-1、N，其中層的編號越大，則越處在上層。那么，我們設(shè)計的架構(gòu)應(yīng)該滿足以下兩個原則：

1.第K（1

2.如果P層依賴Q層，則P的編號一定大于Q。

其中第一個原則，保證了依賴的逐層性，及整個架構(gòu)的依賴是逐層向下的，而不能跨層依賴。第二個原則，則保證了依賴的單向性，及只能上層依賴底層，而不能底層反過來依賴上層。

針對接口編程，而不是針對實現(xiàn)編程
這里所指的接口，不是特指編程語言中的具體語言元素（如C#中由Interface定義的語言接口），而是指一種抽象的，在語義層面上起著接合作用語義體。它的具體實現(xiàn)，可能是接口，可能是抽象類，甚至可能是具體類。

我認(rèn)為，從不同的視角，接口可以有以下兩種定義：

1.接口是一組規(guī)則的集合，它規(guī)定了實現(xiàn)本接口的類或接口必須擁有的一組規(guī)則。體現(xiàn)了自然界“如果你是……則必須能……”的理念。

2.接口是在一定粒度視圖上同類事物的抽象表示。注意這里我強(qiáng)調(diào)了在一定粒度視圖上，因為“同類事物”這個概念是相對的，它因為粒度視圖不同而不同。

具體到N層架構(gòu)中，針對接口編程的意義在部分上是這樣的：
現(xiàn)仍約定將N層架構(gòu)的各層依次編號為1、2、…、K、…、N-1、N，其中層的編號越大，則越處在上層，那么第K層不應(yīng)該依賴具體一個K-1層，而應(yīng)該依賴一個K-1層的接口，即在第K層中不應(yīng)該有K-1層中的某個具體類。

依賴倒置原則

在軟件設(shè)計原則中，有一種重要的思想叫做依賴倒置。它的核心思想是：不能讓高層組件依賴底層組件，而且，不管高層組件和底層組件，兩者都應(yīng)依賴于抽象。

那么，這個原則和我們上面的原則是否矛盾呢？其實并不矛盾。

因為這個原則定義中的“依賴”是指“具體依賴”，而上面定義中的依賴全部指“抽象依賴”。我對這兩種依賴的定義如下：

具體依賴——如果P層中有一個或一個以上的地方實例化了Q層中某個具體類，則說P層具體依賴于Q層。

抽象依賴——如果P層沒有實例化Q層中的具體類，而是在一個或一個以上的地方實例化了Q層中某個接口，則說P層抽象依賴于Q層，也叫接口依賴于Q層。

從這兩個定義可以看到，所謂的依賴倒置原則，正是上面提到針對接口編程，而不是針對實現(xiàn)編程，兩者在本質(zhì)上是統(tǒng)一的。

綜上所述，可以看出，本課題設(shè)計的分層架構(gòu)，應(yīng)該是這樣一種架構(gòu)：
1.N層架構(gòu)的各層依次編號為1、2、…、K、…、N-1、N，其中層的編號越大，則越處在上層。

2.架構(gòu)中僅存在一種依賴，即第K層接口依賴第K-1層，其中1

封裝變化原則

封裝變化的原則定義為：找出應(yīng)用中可能需要變化之處，把它們獨立出來，不要和那些不需要變化的代碼混雜在一起。

開放-關(guān)閉原則

開發(fā)-關(guān)閉原則定義為：對擴(kuò)展開放，對修改關(guān)閉。

具體到N層架構(gòu)中，可以描述為：當(dāng)某一層有了一個新的具體實現(xiàn)時，它應(yīng)該可以在不修改其他層的情況下，與此新實現(xiàn)無縫連接，順利交互。

單一歸屬原則

在這個架構(gòu)中，任何一個操作類都應(yīng)該有單一的職責(zé)，屬于單獨的一層，而不能同時擔(dān)負(fù)兩種職責(zé)或?qū)儆诙鄠�層次（實體類及輔助類可以被多個層使用，但它們不屬于任何一個層，而是獨立存在）。

層次劃分：

目前，典型的分層架構(gòu)是三層架構(gòu)，即自底向上依次是數(shù)據(jù)訪問層、業(yè)務(wù)邏輯層和表示層。

這種經(jīng)典架構(gòu)經(jīng)歷了時間的考驗和實踐的多次檢驗，被認(rèn)為是合理、有效的分層設(shè)計，所以，在本文中，將沿襲這種經(jīng)典架構(gòu)，使用數(shù)據(jù)訪問層、業(yè)務(wù)邏輯層和表示層的三層架構(gòu)體系。

職責(zé)劃分：
目前，在典型的三層架構(gòu)中，對層次各自的職責(zé)劃分并沒有一個統(tǒng)一的規(guī)范，綜合現(xiàn)有的成功實踐和.NET平臺的特殊性，在本文中將三層架構(gòu)的職責(zé)劃分如下：
數(shù)據(jù)訪問層——負(fù)責(zé)與數(shù)據(jù)源的交互，即數(shù)據(jù)的插入、刪除、修改以及從數(shù)據(jù)庫中讀出數(shù)據(jù)等操作。對數(shù)據(jù)的正確性和有效性不負(fù)責(zé)，對數(shù)據(jù)的用途不了解，不負(fù)擔(dān)任何業(yè)務(wù)邏輯。

業(yè)務(wù)邏輯層——負(fù)責(zé)系統(tǒng)領(lǐng)域業(yè)務(wù)的處理，負(fù)責(zé)邏輯性數(shù)據(jù)的生成、處理及轉(zhuǎn)換。對流入的邏輯性數(shù)據(jù)的正確性及有效性負(fù)責(zé)，對流出的邏輯性數(shù)據(jù)及用戶性數(shù)據(jù)不負(fù)責(zé)，對數(shù)據(jù)的呈現(xiàn)樣式不負(fù)責(zé)。

表示層——負(fù)責(zé)接收用戶的輸入、將輸出呈現(xiàn)給用戶以及訪問安全性驗證。對流入的數(shù)據(jù)的正確性和有效性負(fù)責(zé)，對呈現(xiàn)樣式負(fù)責(zé)，對流出的數(shù)據(jù)正確性不負(fù)責(zé)，但負(fù)責(zé)在數(shù)據(jù)不正確時給出相應(yīng)的異常信息。

模塊劃分及交互設(shè)計：

綜合以上分析，可在宏觀上將整個系統(tǒng)分為一下幾個模塊：

實體類模塊——一組實體類的集合，負(fù)責(zé)整個系統(tǒng)中數(shù)據(jù)的封裝及傳遞。

數(shù)據(jù)訪問層接口族——一組接口的集合，表示數(shù)據(jù)訪問層的接口。

業(yè)務(wù)邏輯層接口族——一組接口的集合，表示業(yè)務(wù)邏輯層的接口。

數(shù)據(jù)訪問層模塊——一組類的集合，完成數(shù)據(jù)訪問層的具體功能，實現(xiàn)數(shù)據(jù)訪問層接口族。

業(yè)務(wù)邏輯層模塊——一組類的集合，完成業(yè)務(wù)邏輯層的具體功能，實現(xiàn)業(yè)務(wù)邏輯層接口族。

表示層模塊——程序及可視元素的集合，負(fù)責(zé)完成表示層的具體功能。

IoC容器模塊——負(fù)責(zé)依賴注入的實現(xiàn)。

輔助類模塊——完成全局輔助性功能。

各模塊見交互關(guān)系如下：

圖1

這篇中理論比較多，但是它是整個架構(gòu)的基礎(chǔ)，可以幫助朋友們對將要實現(xiàn)的項目架構(gòu)及要遵循的原則有一個整體的了解。當(dāng)然，在后續(xù)文章中，將主要討論Demo項目的實際開發(fā)過程，那時，這些思想和理論性的東西將得到體現(xiàn)。

分享：基于.NET平臺的分層架構(gòu)實戰(zhàn)(一) 綜述
通過瀏覽博客園的文章發(fā)現(xiàn)，很多朋友對分層架構(gòu)特別感興趣，剛好我剛做完的畢業(yè)設(shè)計就是專門研究.NET平臺上分層架構(gòu)的（題目叫“基于.NET平臺的分層架構(gòu)與設(shè)計模式應(yīng)用研究”）。通過