【文章內(nèi)容簡(jiǎn)介】 具體到 N層架構(gòu)中，針對(duì)接口編程的意義是這樣的：現(xiàn)約定將 N層架構(gòu)的各層依次編號(hào)為 ?、 K、?、 N N，其中層的編號(hào)越大，則越處在上層，那么第 K 層不應(yīng)該依賴(lài)具體一個(gè) K1 層，而應(yīng)該依賴(lài)一個(gè) K1 層的接口，即在第 K 層中不應(yīng)該有 K1 層中的某個(gè)具體類(lèi)。 依賴(lài)倒置原則 在軟件設(shè)計(jì)原則中，有一種重要的思想叫做依賴(lài)倒置。 它的核心思想是：不能讓高層組件依賴(lài)底層組件，而且，不管高層組件和底層組件，兩者都應(yīng)依賴(lài)于抽象。所謂的依賴(lài)倒置原則，其實(shí)就是上面提到針對(duì)接口編程，而不是針對(duì)實(shí)現(xiàn)編程，兩者在本質(zhì)上是統(tǒng)一的。 9 綜上所述，本系統(tǒng)應(yīng)該是這樣一種架構(gòu)： 1) N層架構(gòu)的各層依次編號(hào)為 ?、 K、?、 N N，其中層的編號(hào)越大，則越處在上層。 2) 架構(gòu)中僅存在一種依賴(lài)，即第 K 層接口依賴(lài)第 K1 層，其中 1K=N。 封裝變化 封裝變 化的原則定義為：找出應(yīng)用中可能需要變化之處，把它們獨(dú)立出來(lái)，不要和那些不需要變化的代碼混雜在一起。 開(kāi)放、關(guān)閉原則 開(kāi)發(fā) 關(guān)閉原則定義為：對(duì)擴(kuò)展開(kāi)放，對(duì)修改關(guān)閉。 單一職責(zé)原則 任何一個(gè)類(lèi)都應(yīng)該有單一的職責(zé)，屬于單獨(dú)的一層，而不能同時(shí)擔(dān)負(fù)兩種職責(zé)或?qū)儆诙喔鲗印? 三層架構(gòu)是一種比較成熟的系統(tǒng)架構(gòu)， 通過(guò)將整個(gè)系統(tǒng)分為不同的邏輯塊，大大降低了應(yīng)用系統(tǒng)開(kāi)發(fā)和維護(hù)的成本。 三層架構(gòu) 將數(shù)據(jù)訪(fǎng)問(wèn)和邏輯操作都集中到組件中 ,增強(qiáng)了系統(tǒng)的復(fù)用性。 同時(shí)也使 系統(tǒng)的擴(kuò)展性大大增強(qiáng)。模塊化使得系統(tǒng)很容易在縱向和水平兩個(gè)方向拓展： 一方面可以將系統(tǒng)升級(jí)為更大、更有力的平臺(tái)， 另一方面 也可以適當(dāng)增加規(guī)模來(lái)增強(qiáng)系統(tǒng)的網(wǎng)絡(luò)應(yīng)用。 從開(kāi)發(fā)角度和應(yīng)用角度來(lái)看，三層架構(gòu)比雙層或單層結(jié)構(gòu)都有更大的優(yōu)勢(shì)。三層結(jié)構(gòu)適合群體開(kāi)發(fā)，每人可以有不同的分工，協(xié)同工作使效率倍增。開(kāi)發(fā)雙層或單層應(yīng)用時(shí)，每個(gè)開(kāi)發(fā)人員都應(yīng)對(duì)系統(tǒng)有較深的理解，能力要求很高，開(kāi)發(fā)三層應(yīng)用時(shí)，則可以結(jié)合多方面的人才，只需少數(shù)人對(duì)系統(tǒng)全面了解，從一定程度工降低了開(kāi)發(fā)的難度。 基于以上 優(yōu)點(diǎn) 本系統(tǒng)采用三層架構(gòu) 來(lái)開(kāi)發(fā)。 實(shí)體介紹 根據(jù)對(duì)本博客系統(tǒng)的簡(jiǎn)要需求分析，可以確定 以下 幾個(gè)實(shí)體： ? 用 戶(hù)信息：代表用戶(hù)，包括了用戶(hù)的登錄名、密碼、個(gè)性設(shè)置等。 ? 博客留言：代表一些人對(duì)博客的評(píng)價(jià)等信息。 ? 博客信息：包含了博客的基本信息，如博客名稱(chēng)、訪(fǎng)問(wèn)人數(shù)、主題等。 ? 文章：就是文章實(shí)體，包含文章的基本信息，如標(biāo)題、內(nèi)容、發(fā)布時(shí)間等。 ? 文章分類(lèi)：就是文章的類(lèi)別。 10 ? 文章評(píng)論：代表了對(duì)于莫一篇文章發(fā)表的評(píng)論。 ? 照片：代表照片基本信息。 ? 照片分類(lèi)：代表照片的分類(lèi)。 數(shù)據(jù)庫(kù)設(shè)計(jì) 圖 22數(shù)據(jù)庫(kù)表 整個(gè)系統(tǒng)涉及的數(shù)據(jù)庫(kù)的表有 8張，各個(gè)表之間的關(guān)系如圖 22。以下是各個(gè)表的簡(jiǎn)要說(shuō)明： ? UserInfo：用戶(hù) 表。主要保存了博主的相關(guān)信息。 ? Leavewords：留言表。主要保存訪(fǎng)問(wèn)者對(duì)整個(gè) Blog 的評(píng)論。 ? BlogInfo：博客表。主要存放 Blog 的基本設(shè)置信息。 ? PhotoCategory：圖片分類(lèi)表。主要存放圖片的分類(lèi)信息。 ? Photo：圖片表。主要存放圖片信息。 ? PostCategory：文章分類(lèi)表。文章分類(lèi)信息。 ? Post：文章表。文章的基本信息 。 ? Comment: 文章評(píng)論表。文章的相關(guān)評(píng)論信息。 11 圖 23完整顯示了整個(gè)系統(tǒng)設(shè)計(jì)到的表。 圖 23數(shù)據(jù)庫(kù)表 存儲(chǔ)過(guò)程是 SQL 語(yǔ)句和可選控制流語(yǔ)句的 預(yù)編譯集合，以一個(gè)名稱(chēng)存儲(chǔ)并作為一個(gè)單元處理。存儲(chǔ)過(guò)程存儲(chǔ)在數(shù)據(jù)庫(kù)內(nèi)，可由應(yīng)用程序通過(guò)一個(gè)調(diào)用執(zhí)行，而且允許聲明變量、有條件執(zhí)行以及其它強(qiáng)大的編程功能。存儲(chǔ)過(guò)程在創(chuàng)建時(shí)即在服務(wù)器上進(jìn)行編譯，所以執(zhí)行起來(lái)比單個(gè) SQL 語(yǔ)句快 。 由于存儲(chǔ)過(guò)程在性能上和功能上相對(duì)于單個(gè) SQL 語(yǔ)句有較大的優(yōu)勢(shì)，所以在系統(tǒng)中采用存儲(chǔ)過(guò)程。 圖 24展示了系統(tǒng)所用到的存儲(chǔ)過(guò)程。 圖 24 存儲(chǔ)過(guò)程 12 實(shí)體類(lèi)的設(shè)計(jì) 與實(shí)現(xiàn) 實(shí)體類(lèi)是對(duì)實(shí)體的封裝，它通常包括私有變量及對(duì)應(yīng)的 get、 set 方法，而在 C語(yǔ)言中，將 get、 set 方法又組合成屬性。這些私有變量或者屬性，則對(duì)應(yīng)現(xiàn)實(shí)實(shí)體相應(yīng)的屬性。實(shí)體類(lèi)的作用主要有兩個(gè)，一是作為現(xiàn)實(shí)實(shí)體的計(jì)算機(jī)代表，二是數(shù)據(jù)的傳遞。在分層架構(gòu)的應(yīng)用中，數(shù)據(jù)正是封裝在實(shí)體類(lèi)中，然后以實(shí)體類(lèi)為載體在各個(gè)層次間傳遞。這樣不但符合面向?qū)ο笤O(shè)計(jì)的原則，也便于對(duì)數(shù)據(jù)存取進(jìn)行控制。理想情況下，實(shí)體類(lèi)中不能含有任何邏輯，它應(yīng)該單純是數(shù)據(jù)的封裝。所以，它不應(yīng)該有方法，當(dāng)然構(gòu)造函數(shù)除外?；谝陨戏治?，我們?cè)O(shè)計(jì)的實(shí)體類(lèi)，應(yīng)該是準(zhǔn)確、干凈、易用。準(zhǔn)確表明實(shí)體類(lèi)應(yīng)該準(zhǔn)確無(wú)誤地表示現(xiàn)實(shí)中的實(shí)體，干凈表示實(shí)體類(lèi)應(yīng)該僅包含數(shù)據(jù) 的封裝而不摻雜任何邏輯或者與數(shù)據(jù)封裝無(wú)關(guān)的東西，易用表示實(shí)體類(lèi)應(yīng)該很容易地用來(lái)在各層之間傳遞數(shù)據(jù)。 本系統(tǒng)不需考慮特殊實(shí)體類(lèi)的情況，僅需編寫(xiě)簡(jiǎn)單的實(shí)體類(lèi)即可。詳細(xì)信息請(qǐng)參見(jiàn)相關(guān)代碼。 完整的類(lèi)庫(kù)如圖 25所示。 圖 25 實(shí)體類(lèi)庫(kù) 接口 設(shè)計(jì) 接口有以下幾個(gè)作用： ? 接口明確了各層次的職責(zé)。 ? 接口決定了各個(gè)層次具體需要實(shí)現(xiàn)的功能。 ? 接口形成了整個(gè)分層架構(gòu)的骨架 。 ? 接口暴露了層次的 API，為上層提供了依賴(lài)點(diǎn)。 因此，接口的設(shè)計(jì)實(shí)際上處在現(xiàn)實(shí)需求和程序?qū)崿F(xiàn)之間，起到承上啟下的用。它決定了需求 分析中的各個(gè)需求如何合理地映射成各個(gè)層次的不同方法。所以接口的設(shè)計(jì)應(yīng)該在需求分析的基礎(chǔ)上進(jìn)行。 13 本系統(tǒng)中主要需要設(shè)計(jì) 的接口有：數(shù)據(jù)訪(fǎng)問(wèn)層接口、業(yè)務(wù)邏輯層接口。 數(shù)據(jù)訪(fǎng)問(wèn)層接口 數(shù)據(jù)訪(fǎng)問(wèn)層負(fù)責(zé)與數(shù)據(jù)源的交互，負(fù)責(zé)數(shù)據(jù)的創(chuàng)建、刪除、更新及查詢(xún)工作。它不應(yīng)該包含任何業(yè)務(wù)邏輯或可視性元素，對(duì)它所處理數(shù)據(jù)的業(yè)務(wù)意義是“無(wú)知”的。它與數(shù)據(jù)庫(kù)系統(tǒng)一起負(fù)責(zé)數(shù)據(jù)完整性。 在三層模型中，數(shù)據(jù)訪(fǎng)問(wèn)層為上層（業(yè)務(wù)邏輯層）提供 了服務(wù) ， 數(shù)據(jù)訪(fǎng)問(wèn)層的接口規(guī)定了數(shù)據(jù)訪(fǎng)問(wèn)層的功能，業(yè)務(wù)邏輯層針對(duì)接口進(jìn)行編程， 不管數(shù)據(jù)訪(fǎng)問(wèn)層如何變化，只要接口不 變，業(yè)務(wù)邏輯層都不需要變動(dòng)。 這樣在開(kāi)發(fā)系統(tǒng)中將可變因素減少到最少 ，這也就是分層架構(gòu)的最基本的思想：針對(duì)接口編程，而不針對(duì)實(shí)現(xiàn)編程 。 以下列出 本系統(tǒng)中 完整的類(lèi)庫(kù) ， 如圖 26所示。 圖 26 數(shù)據(jù)訪(fǎng)問(wèn)層接口 業(yè)務(wù)邏輯層接口 在設(shè)計(jì)業(yè)務(wù)邏輯層接口之前，需要對(duì)業(yè)務(wù)邏輯層的職責(zé)進(jìn)行明確。 業(yè)務(wù)邏輯層的職責(zé)敘述如下：業(yè)務(wù)邏輯層負(fù)責(zé)完成與系統(tǒng)領(lǐng)域相關(guān)的業(yè)務(wù)邏輯操作，實(shí)現(xiàn)過(guò)程中的數(shù)據(jù)訪(fǎng)問(wèn)操作通過(guò)調(diào)用數(shù)據(jù)訪(fǎng)問(wèn)層實(shí)現(xiàn)。它對(duì)業(yè)務(wù)相關(guān)的數(shù)據(jù)有效性負(fù)責(zé)，但是不負(fù)責(zé) UI 輸入數(shù)據(jù)的有效性。業(yè)務(wù)邏輯層中不能含有與顯示相關(guān)的邏輯，不能決 定或影響數(shù)據(jù)最終的呈現(xiàn)樣式。 由于不同領(lǐng)域的業(yè)務(wù)邏輯差別很大，所以無(wú)法像數(shù)據(jù)訪(fǎng)問(wèn)層那樣對(duì)接口操作做出明確的分類(lèi)。在實(shí)際項(xiàng)目開(kāi)發(fā)中，業(yè)務(wù)邏輯層接口的設(shè)計(jì)往往要和領(lǐng)域?qū)＜液献?。而在?博客系統(tǒng) 中，由于 業(yè)務(wù)邏輯都是比較簡(jiǎn)單的 ，所以不用進(jìn)行專(zhuān)門(mén)的領(lǐng)域邏輯調(diào)研。 完整的類(lèi)庫(kù)如圖 27所示。 14 圖 27 業(yè)務(wù)邏輯層接口 IoC 容器及依賴(lài)注入機(jī)制的設(shè)計(jì) IoC 容器及依賴(lài)注入機(jī)制的設(shè)計(jì) 依賴(lài)注入（ Dependency Injection）和控制反轉(zhuǎn)（ Inversion of Control）是同一個(gè)概念。 具體含義是：當(dāng)某個(gè)角色（調(diào)用者）需要另一個(gè)角色（被調(diào)用者）的協(xié)助時(shí)，在傳統(tǒng)的程序設(shè)計(jì)過(guò)程中，通常由調(diào)用者來(lái)創(chuàng)建被調(diào)用者的實(shí)例。但在具有依賴(lài)注入的系統(tǒng)里，創(chuàng)建被調(diào)用者的工作不再由調(diào)用者來(lái)完成，因此稱(chēng)為控制反轉(zhuǎn)。創(chuàng)建被調(diào)用者實(shí)例的工作通常由 Ioc 容器來(lái)完成，然后注入調(diào)用者，因此也稱(chēng)為依賴(lài)注入。 具體到分層架構(gòu)中，依賴(lài)注入可以這樣理解：當(dāng)上層類(lèi)的需要調(diào)用下層類(lèi)功能時(shí)，不再是由上層類(lèi)直接實(shí)例化下層類(lèi)，而是通過(guò) IoC 容器獲取一個(gè)下層類(lèi)的實(shí)例，然后注入到上層類(lèi)中。 IoC 容器負(fù)責(zé)根據(jù)配置信息，創(chuàng)建不同的數(shù)據(jù) 訪(fǎng)問(wèn)層及業(yè)務(wù)邏輯層實(shí)例，并將其注入到業(yè)務(wù)邏輯層與表示層中，從而實(shí)現(xiàn)三個(gè)層次的解耦。 依賴(lài)注入機(jī)制的實(shí)現(xiàn)有兩種途徑，一種是使用現(xiàn)有的框架。如 J2EE 平臺(tái)上的 Spring 框架就可以很好的完成依賴(lài)注入功能，在 .NET 平臺(tái)上有 等框架可以選擇。另一種途徑，就是自己編寫(xiě)相應(yīng)的代碼，完成依賴(lài)注入機(jī)制。 鑒于 .NET 平臺(tái)上的“反射”機(jī)制對(duì)依賴(lài)注入的實(shí)現(xiàn)非常方便，所以本 系統(tǒng) 將采用第二種方案，使用 Abstract Factory 設(shè)計(jì)模式和反射機(jī)制完成依賴(lài)注入的設(shè)計(jì)。 Abstract Factory 模式的應(yīng)用 Abstract Factory 模式是在依賴(lài)注入機(jī)制中廣泛采用的設(shè)計(jì)模式， Spring 的 IoC 容器就采用了這個(gè)經(jīng)典模式。它的中文譯名叫做“抽象工廠(chǎng)” ， 其定義是這樣的：提供一個(gè)接口，用于創(chuàng)建相關(guān)或依賴(lài)對(duì)象的家族，而不需要指定具體類(lèi)。 以數(shù)據(jù)訪(fǎng)問(wèn)層注入到業(yè)務(wù)邏輯層為例（業(yè)務(wù)邏輯層注入到表示層的原理類(lèi)似） ，先假設(shè) 該博客 系統(tǒng) 中 僅有用戶(hù)和 文章 兩個(gè)實(shí)體，并且我們的系統(tǒng)需要能訪(fǎng)問(wèn) SQLServer 和 15 Oracle 兩個(gè)數(shù)據(jù)庫(kù)，那么，系統(tǒng)中就需 要 SQLServerDAL 和 OracleDAL 兩個(gè)數(shù)據(jù)訪(fǎng)問(wèn)層，它 們 都 含有 兩 個(gè)數(shù) 據(jù) 訪(fǎng)問(wèn) 類(lèi) ，分 別 是 SQLServerUserDAL 、 SQLServerPostDAL 和 OracleUserDAL、 OraclePostDAL。此時(shí)，用戶(hù)和帖子的業(yè)務(wù)邏輯層類(lèi) UserBLL 與 PostBLL 作為客戶(hù)類(lèi)，不應(yīng)該與具體的數(shù)據(jù)訪(fǎng)問(wèn)層類(lèi)耦合，而應(yīng)該先定義接口 IUserDAL 與 IPostDAL 接 口 ， 讓 業(yè) 務(wù) 邏 輯 層 與 這 兩 個(gè) 接 口 耦 合 。 再 設(shè) 計(jì) SQLServerDALFactory 與 OracleDALFactory，分別作為生成兩種數(shù)據(jù)訪(fǎng)問(wèn)層的工廠(chǎng)，最后通過(guò) 配置信息，決定在業(yè)務(wù)邏輯層中實(shí)例化哪個(gè)工廠(chǎng) 。如圖 28所示。 圖 28 Ioc容器注入原理 Abstract Factory 模式雖然可以完成依賴(lài)注入的機(jī)制的設(shè)計(jì)，但是其本身也有缺陷。從上文可以看出，就數(shù)據(jù)訪(fǎng)問(wèn)層而言，每個(gè)數(shù)據(jù)訪(fǎng)問(wèn)層實(shí)現(xiàn)都要對(duì)應(yīng)一個(gè)工廠(chǎng)，業(yè)務(wù)邏輯層當(dāng)然也是如此。并且以后每當(dāng)添加一個(gè)新的實(shí)現(xiàn)，都要寫(xiě)一個(gè)相應(yīng)的工廠(chǎng)。因此，當(dāng)層次的實(shí)現(xiàn)過(guò)多時(shí)，整個(gè)系統(tǒng)就會(huì)存在很多工廠(chǎng)，這些工廠(chǎng)不僅使代碼變得臃腫，也難以維護(hù)。 .NET 平臺(tái)上，有一種叫“反射”的機(jī)制，利用這種機(jī)制，可以簡(jiǎn)化 Abstract Factory設(shè)計(jì)模式的代碼。而利用反射機(jī)制簡(jiǎn)化后的 Abstract Factory 則可以叫做 Reflection Abstract Factory，也叫反射工廠(chǎng)。 反射就是動(dòng)態(tài)發(fā)現(xiàn)類(lèi)型信息的能力。它幫助程序設(shè)計(jì)人員在程序運(yùn)行時(shí)利用一些信息去動(dòng)態(tài)地使用類(lèi)型，這些信息在設(shè)計(jì)時(shí)是未知的，這種能力可以用于后期綁定。反射還支持的 16 更高級(jí)的行為，能在運(yùn)行時(shí)動(dòng)態(tài)創(chuàng)建新類(lèi)型，并且對(duì)這些新類(lèi)型的操作進(jìn)行調(diào)用。 有了反射機(jī)制，我們就可以從配置文件（一般是在 ）讀出配置信息后，不是根據(jù)這個(gè)信息實(shí)例化相應(yīng)的 工廠(chǎng)，而是讓反射工廠(chǎng)通過(guò)這些信息，動(dòng)態(tài)加載相應(yīng)程序集中的類(lèi)，這樣每個(gè)層次只需要一個(gè)工廠(chǎng)就可以完成依賴(lài)注入，即使以后出現(xiàn)新的實(shí)現(xiàn)，也不需要修改或添加工廠(chǎng)，只要在配置文件中寫(xiě)明程序集的名字即可。如果考慮到性能和易用性，可以配合緩存機(jī)制和 Facade 設(shè)計(jì)模式進(jìn)一步優(yōu)化 IoC 的設(shè)計(jì)。 最終反射工廠(chǎng)結(jié)構(gòu)圖如圖29所示。 圖 29 反射工廠(chǎng)結(jié)構(gòu)圖 圖 210 反射工廠(chǎng)示意圖 在圖 210中 DALFactory 和 BLLFactory 的實(shí)例化箭頭直接指向了 IDAL 和 IBLL。實(shí)際上， IDAL 和 IBLL 分別是一個(gè)工程，它里面是一組接口，這里不是指工廠(chǎng)直接實(shí)例化接口 17 （實(shí)際上接口也是不可能被實(shí)例化的）。 使用反射機(jī)制后，同一層次的不同實(shí)現(xiàn)分別放在不同工程下，而里面包含的各個(gè)類(lèi)的名字是一致的。例如 SQLServerDAL 下和 OracleDAL 下都有 UserInfoDAL，至于運(yùn)行時(shí)具體實(shí)例化哪個(gè)，是通過(guò) 中配置實(shí)現(xiàn)的。也就是說(shuō) 決定了實(shí)例化哪個(gè)工程下的 UserInfoDAL。 數(shù)據(jù) 訪(fǎng)問(wèn)層的實(shí)現(xiàn) 數(shù)據(jù)訪(fǎng)問(wèn)層的實(shí)現(xiàn)一般有兩種方式： 基于樸素的 實(shí)現(xiàn)和基于 ORM 框架的實(shí)現(xiàn) 。對(duì)于 ORM由于篇幅原因不做過(guò)多描述。本系統(tǒng)采用 數(shù)據(jù)訪(fǎng)問(wèn)層的樸素實(shí)現(xiàn)，就是指?jìng)鹘y(tǒng)的通過(guò)執(zhí)行 SQL 語(yǔ)句或調(diào)用存儲(chǔ)過(guò)程實(shí)現(xiàn)對(duì)數(shù)據(jù)庫(kù)的操作。 .NET 平臺(tái)內(nèi)置了豐富的對(duì)數(shù)據(jù)庫(kù)進(jìn)行操作的類(lèi)庫(kù)，因此數(shù)據(jù)訪(fǎng)問(wèn)層的樸素實(shí)現(xiàn)非常方便。 具體到本課題中，數(shù)據(jù)訪(fǎng)問(wèn)層的樸素實(shí)現(xiàn)操作一般分為 以下兩種方式 。 使用動(dòng)態(tài) SQL 語(yǔ)句： 1. 獲取參數(shù)。 2. 動(dòng)態(tài)組合 SQL 語(yǔ)句。 3. 執(zhí)行 SQL 語(yǔ)句。 4. 返回結(jié)