【文章內(nèi)容簡介】 Demo中，特指數(shù)據(jù)訪問層接口和業(yè)務(wù)邏輯層接口。 接口在技術(shù)上編寫難度不大，但是其意義十分重大?？傮w來說，接口有著一下幾個作用： ?? 接口明確了各層次的職責(zé)。 ?? 接口決定了各個層次具體需要實現(xiàn)的功能。 ?? 接口形成了整個分層架構(gòu)的骨架 ?? 接口暴露了層次的API，為上層提供了依賴點。 因此，接口的設(shè)計實際上處在現(xiàn)實需求和程序?qū)崿F(xiàn)之間，起到承上啟下的用。它決定了需求分析中的各個需求如何合理地映射成各個層次的不同方法。所以接口的設(shè)計應(yīng)該在需求分析的基礎(chǔ)上進行。 數(shù)據(jù)訪問層接口的設(shè)計 因為接口直接關(guān)系到層次的職責(zé)，所以，在設(shè)計數(shù)據(jù)訪問層接口之前，需要對數(shù)據(jù)訪問層的職責(zé)進行明確。 在本課題中，將數(shù)據(jù)訪問層職責(zé)敘述如下：數(shù)據(jù)訪問層負(fù)責(zé)與數(shù)據(jù)源的交互，負(fù)責(zé)數(shù)據(jù)的創(chuàng)建、刪除、更新及查詢工作。它不應(yīng)該包含任何業(yè)務(wù)邏輯或可視性元素，對它所處理數(shù)據(jù)的業(yè)務(wù)意義是“無知”的。它與數(shù)據(jù)庫系統(tǒng)一起負(fù)責(zé)數(shù)據(jù)完整性。 具體來說，數(shù)據(jù)訪問層的接口一般包含以下幾種類型的操作： 創(chuàng)建：在數(shù)據(jù)庫中插入新記錄，無返回值或返回表示操作狀態(tài)的標(biāo)志值。 刪除：在數(shù)據(jù)庫中刪除符合條件的記錄，一般無返回值或返回表示操作狀態(tài)的標(biāo)志值。 更新：將數(shù)據(jù)庫中符合條件的記錄更新，一般無返回值或返回表示操作狀態(tài)的標(biāo)志值。 單實體查詢：從數(shù)據(jù)庫中讀出符合條件單條記錄的信息，一般返回單個實體類。 集合實體查詢：從數(shù)據(jù)庫中讀出符合條件的多條記錄的信息，一般返回實體類集合。 函數(shù)查詢：根據(jù)一定的函數(shù)規(guī)則，根據(jù)數(shù)據(jù)記錄查詢相應(yīng)的函數(shù)值，如查詢某個表的記錄數(shù)目，返回指定函數(shù)值。 以實體用戶為例，根據(jù)需求分析，數(shù)據(jù)訪問層接口設(shè)計如表所示。需求接口參數(shù)返回值操作類型獲取用戶信息GetModel用戶名用戶實體類單實體查詢獲取全部用戶GetModelList無用戶實體類集合實體查詢獲取特定狀態(tài)用戶GetModelList用戶狀態(tài)用戶實體類集合實體查詢添加新用戶AddUser用戶實體類表示是否成功的布爾值 創(chuàng)建刪除用戶DeleteUser用戶ID表示是否成功的布爾值刪除更新用戶信息UpdateUser用戶實體類表示是否成功的布爾值更新修改用戶密碼UpdatePwd用戶實體類表示是否成功的布爾值更新修改用戶狀態(tài)UpdateUserState用戶狀態(tài)ID、用戶ID表示是否成功的布爾值更新判斷是否存在此用戶IsExist用戶名表示是否成功的布爾值函數(shù)查詢 具體IUsersDAL的實現(xiàn)代碼請參考附錄一 業(yè)務(wù)邏輯層接口的設(shè)計 與數(shù)據(jù)訪問層接口的設(shè)計一樣，在設(shè)計業(yè)務(wù)邏輯層的接口前，首先應(yīng)明確其職責(zé)。 本課題將業(yè)務(wù)邏輯層的職責(zé)敘述如下：業(yè)務(wù)邏輯層負(fù)責(zé)完成與系統(tǒng)領(lǐng)域相關(guān)的業(yè)務(wù)邏輯操作，實現(xiàn)過程中的數(shù)據(jù)訪問操作通過調(diào)用數(shù)據(jù)訪問層實現(xiàn)。它對業(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ù)邏輯差別很大，所以無法像數(shù)據(jù)訪問層那樣對接口操作做出明確的分類。 在實際項目開發(fā)中，業(yè)務(wù)邏輯層接口的設(shè)計往往要和領(lǐng)域?qū)＜液献?。而在本課題的Demo中，由于網(wǎng)上購物系統(tǒng)的領(lǐng)域業(yè)務(wù)大家都很熟悉，所以不用進行專門的領(lǐng)域邏輯調(diào)研。 下面以用戶實體為例，業(yè)務(wù)邏輯層接口設(shè)計如表所示。需求接口參數(shù)返回值操作類型獲取用戶信息GetModel用戶名用戶實體類單實體查詢獲取全部用戶GetModelList無用戶實體類集合實體查詢獲取特定狀態(tài)用戶GetModelList用戶狀態(tài)用戶實體類集合實體查詢添加新用戶AddUser用戶實體類表示是否成功的布爾值 創(chuàng)建刪除用戶DeleteUser用戶ID表示是否成功的布爾值刪除更新用戶信息UpdateUser用戶實體類表示是否成功的布爾值更新修改用戶密碼UpdatePwd用戶實體類表示是否成功的布爾值更新修改用戶狀態(tài)UpdateUserState用戶狀態(tài)ID、用戶ID表示是否成功的布爾值更新判斷是否存在此用戶IsExist用戶名表示是否成功的布爾值函數(shù)查詢具體UsersBLL的實現(xiàn)代碼請參考附錄一。四、三層架構(gòu)中常用的設(shè)計模式 依賴注入與控制反轉(zhuǎn) 依賴注入（Dependency Injection）和控制反轉(zhuǎn)（Inversion of Control）是同一個概念。具體含義是：當(dāng)某個角色（調(diào)用者）需要另一個角色（被調(diào)用者）的協(xié)助時，在傳統(tǒng)的程序設(shè)計過程中，通常由調(diào)用者來創(chuàng)建被調(diào)用者的實例。但在具有依賴注入的系統(tǒng)里，創(chuàng)建被調(diào)用者的工作不再由調(diào)用者來完成，因此稱為控制反轉(zhuǎn)。創(chuàng)建被調(diào)用者實例的工作通常由Ioc容器來完成，然后注入調(diào)用者，因此也稱為依賴注入。 具體到分層架構(gòu)中，依賴注入可以這樣理解：當(dāng)上層類的需要調(diào)用下層類功能時，不再是由上層類直接實例化下層類，而是通過IoC容器獲取一個下層類的實例，然后注入到上層類中。 以用戶實體的業(yè)務(wù)邏輯層調(diào)用數(shù)據(jù)訪問層為例，在沒有依賴注入機制的系統(tǒng)中，用戶的業(yè)務(wù)邏輯層類直接實例化數(shù)據(jù)訪問層類，(a)所示。在加入依賴注入機制后，實例化數(shù)據(jù)訪問層的任務(wù)就交給了IoC容器，(b)所示（a）非IoC耦合示意(b) IoC耦合示意 這樣做的好處是什么呢？前面已經(jīng)提到過，在我們設(shè)計的分層架構(gòu)中層次之間一定不能出現(xiàn)具體耦合。(a)的模式，業(yè)務(wù)邏輯層勢必要實例化具體的數(shù)據(jù)訪問層類，這就造成了緊耦合。而在依賴注入機制下，業(yè)務(wù)邏輯層可以只依賴數(shù)據(jù)訪問層的接口，至于在運行時得到的是哪種數(shù)據(jù)訪問層類，它并不需要知道，他只需從IoC中獲得相應(yīng)的類，然后調(diào)用它的方法完成任務(wù)就行了。而IoC內(nèi)部可以有一套配置機制，這樣就可以根據(jù)不同的配置信息，動態(tài)決定實例化那一種數(shù)據(jù)訪問層類，從而實現(xiàn)了兩個層次間的解耦。由于團隊的各方面的因素，(a)的模式。(b) 的模式并不展開討論，想了解這方面知識的讀者請查閱相關(guān)的資料。 Abstract Factory模式在三層架構(gòu)的應(yīng)用 Abstract Factory模式是在依賴注入機制中廣泛采用的設(shè)計模式，Spring的IoC容器就采用了這個經(jīng)典模式。它的中文譯名叫做“抽象工廠”，其定義是這樣的：提供一個接口，用于創(chuàng)建相關(guān)或依賴對象的家族，而不需要指定具體類。 Factory模式的示意圖。IFactory為工廠接口，它內(nèi)部定義了生產(chǎn)一系列產(chǎn)品的方法。其它所有工廠都必須實現(xiàn)這個接口，但它們生產(chǎn)的產(chǎn)品系列是不一樣的，而一系列產(chǎn)品的每一種產(chǎn)品都實現(xiàn)自同一個產(chǎn)品接口。這樣，客戶（Client）僅需要依賴工廠接口和產(chǎn)品接口。如果配置文件決定實例化哪一個工廠，則客戶就能在運行時動態(tài)獲得不同的產(chǎn)品系列，從而系統(tǒng)獲得了依賴注入的功能。 下面具體到本課題中，討論抽象工廠在依賴注入機制中的應(yīng)用。以數(shù)據(jù)訪問層注入到業(yè)務(wù)邏輯層為例（業(yè)務(wù)邏輯層注入到表示層的原理類似），先假設(shè)系統(tǒng)僅有用戶一個實體，并且我們的系統(tǒng)需要能訪問SQLServer和Access兩個數(shù)據(jù)庫，那么，系統(tǒng)中就需呀SqlServerDAL和AccessDAL兩個數(shù)據(jù)訪問層，它們都含有一個數(shù)據(jù)訪問類，分別是SqlServerUsersDAL（對應(yīng)本文實例工程BookStoreDAL中SqlServer文件夾下的Users）和AccessUsersDAL（對應(yīng)本文實例工程BookStoreDAL中Access文件夾下的Users）。此時，用戶的業(yè)務(wù)邏輯層類UsersBLL（對應(yīng)本文實例工程BookStoreBLL中的Users）作為客戶類，不應(yīng)該與具體的數(shù)據(jù)訪問層類耦合，而應(yīng)該先定義接口IUsersDAL（對應(yīng)本文實例工程BookStoreiDAL中的IUsers）接口，讓業(yè)務(wù)邏輯層與這個接口耦合。再設(shè)計SqlServerDALFactory與AccessDALFactory，分別作為生成兩種數(shù)據(jù)訪問層的工廠，最后通過配置信息，決定在業(yè)務(wù)邏輯層中實例化哪個工廠。 抽象工廠模式在三層架構(gòu)中的應(yīng)用 三層架構(gòu)中的外觀模式（Facade） 外觀模式（Facade）為子系統(tǒng)中的一組接口提供一個一致的界面，此模式定義了一個高層接口，這個接口使得這一子系統(tǒng)更加容易使用[1] 外觀模式（Facade）結(jié)構(gòu)圖。在設(shè)計初期階段，應(yīng)該要有意識的講不同的兩個層分離。經(jīng)典的三層架構(gòu)，就需要考慮在數(shù)據(jù)訪問層、業(yè)務(wù)邏輯層和表示層的層與層之間建立外觀Facade，這樣可以為復(fù)雜的子系統(tǒng)提供一個簡單的接口，使得耦合大大降低。致謝 感謝指導(dǎo)老師對我的關(guān)心、鼓勵與幫助；感謝同學(xué)張三、李四和王五的熱情支持和真誠幫助；感謝家人在十幾年的求學(xué)生涯中，給予的教導(dǎo)、愛護與支持，促使我在人生的道路上不斷奮力前行。由于自身知識的不足，文中必存在不少疏漏和不足。敬請老師提出寶貴的意見，并衷心感謝。[參考文獻(xiàn)] [1]Erich Gamm, Richard Helm, Ralph Johnson, ：可復(fù)用面向?qū)ο筌浖幕A(chǔ)[M].北京:機械工業(yè)出版社，2007.[2]Robert ：原則、模式與實踐[M].北京:清華大學(xué)出版社，2003.[3][M].北京:電子工業(yè)出版社，2002.[4]Martin [M].北京:機械工業(yè)出版社,2010.[5]甄鐳..NET與設(shè)計模式[M].北京:電子工業(yè)出版社,2005.[6][M].北京:清華大學(xué)出版社,2007.[7] CSDN，[8] 博客園，[9] Google，[10] 百度，附錄一：代碼摘要用戶實體類：using System。using 。using 。namespace BookStoreModels{ [Serializable()] public class Users { public Users() { } private int id = 0。 /// summary /// Id /// /summary public int Id { get { return id。 } set { id = value。 } } private string loginId = 。 /// summary /// 用戶Id /// /summary public string LoginId { get { return loginId。 } set { loginId = value。 } } private string loginPwd = 。 /// summary /// 用戶密碼 /// /summary public string LoginPwd { get { r