基于.NET平臺的分層架構(gòu)實戰(zhàn)

1、基于.NET平臺的分層架構(gòu)實戰(zhàn)（一）綜述（本文來自 晚12：34整理完）通過瀏覽博客園的文章發(fā)現(xiàn)，很多朋友對分層架構(gòu)特別感興趣，剛好我剛做完的畢業(yè)設(shè)計就是專門研究.NET平臺上分層架構(gòu)的（題目叫“基于.NET平臺的分層架構(gòu)與設(shè)計模式應用研究”）。通過做這篇論文，我對分層架構(gòu)有了一定的了解，所以，就萌發(fā)了想寫一個文章系列，詳述一下分層架構(gòu)。然而，論文的理論性太強，不適合在網(wǎng)上發(fā)布，尤其不適合初學者理解，所以，我想在這個文章系列中，少講理論，而是通過做一個完整的案例來討論分層架構(gòu)的基本方法，這樣會直觀很多。希望在這個文章系列的寫作過程中，能和朋友們一起學習，一起進步。 為了讓朋友們把主要精力放在理

2、解分層架構(gòu)而不是案例本身，我準備選擇一個相對簡單的留言本系統(tǒng)作為Demo，這個系統(tǒng)的名字就叫做NGuestBook。初步計劃將這個文章系列分為以下幾篇：1.綜述2.系統(tǒng)需求分析及數(shù)據(jù)庫設(shè)計3.架構(gòu)概要設(shè)計4.實體類的實現(xiàn)5.接口的設(shè)計與實現(xiàn)6.依賴注入及IoC的設(shè)計與實現(xiàn)7.數(shù)據(jù)訪問層的第一種實現(xiàn)Access+動態(tài)生成SQL語言8.數(shù)據(jù)訪問層的第二種實現(xiàn)SQLServer+存儲過程9.數(shù)據(jù)訪問層的第三種實現(xiàn)基于NBear框架的ORM實現(xiàn)10.業(yè)務邏輯層的實現(xiàn)11.表示層的實現(xiàn)12.使用ASP.NET AJAX框架對表示層進行改進13.總結(jié) 當然，以上只是初步計劃，在寫文章的過程中可能會根據(jù)具體

3、情況適當調(diào)整，但是內(nèi)容大體就是這些。 這個文章系列不會對所用到的技術(shù)進行詳細講解，具體請參考相關(guān)文獻，閱讀文章前最好能對以下技術(shù)有一個了解：1.C#語言2.ASP.NET3.設(shè)計模式4.關(guān)系數(shù)據(jù)庫基礎(chǔ)知識5.軟件架構(gòu)基本原則與軟件工程基礎(chǔ)知識6.基于NBear框架的ORM技術(shù)7.JavaScript,Ajax8.ASP.NET AJAX框架（特別是客戶端編程）9.HTML,CSS,標準化布局 另外，本文章系列是基于.NET framework2.0框架平臺進行討論，3.5平臺的新特性（如LINQ、ASP.NET MVC等）不會討論，IDE使用Visual Studio 2005，數(shù)據(jù)庫會用到S

4、QLServer2005 Express和Access2003?；?NET平臺的分層架構(gòu)實戰(zhàn)（二）需求分析與數(shù)據(jù)庫設(shè)計在實際的項目中，需求分析和數(shù)據(jù)庫的設(shè)計是很重要的一個環(huán)節(jié)，這個環(huán)節(jié)會直接影響項目的開發(fā)過程和質(zhì)量。實際中，這個環(huán)節(jié)不但需要系統(tǒng)分析師、軟件工程師等計算機方面的專家，還需要相關(guān)領(lǐng)域的領(lǐng)域?qū)＜覅⑴c才能完成。 但是，在這個文章系列中，所要使用的Demo僅僅是一個例子，而且其業(yè)務極為簡單，因此，這里并不是真正的需求分析和數(shù)據(jù)庫設(shè)計，而是將Demo的需求和數(shù)據(jù)庫羅列至此，使朋友們對Demo有一個大體的了解，方便后續(xù)文章中開發(fā)過程的理解。需求分析：這個項目是一個留言本，其業(yè)務極為簡單，現(xiàn)

5、將其描述如下。1.任何訪問者可以進行留言，留言完成后，不會立即顯示正文，而是要經(jīng)過管理員驗證后才可顯示。2.任何訪問者可以對留言發(fā)表評論，未通過驗證的留言不可以評論。3.管理員可以對留言進行回復（這個回復不同于評論，是直接顯示在正文下面，而且是一個留言只能有一個回復），并可對留言與評論實行刪除，以及對留言進行通過驗證操作。4.管理員分為超級管理員和普通管理員。超級管理員只有一個，負責對普通管理員實行添加、刪除操作。普通管理員可偶多個，負責對留言的管理，并可以修改自己的登錄密碼。這個項目的用例圖如下：數(shù)據(jù)庫設(shè)計：設(shè)計數(shù)據(jù)表之前，首先進行實體和關(guān)系的識別與確定。通過需求分析，可以觀察得出，本項目的

6、實體有：管理員（不包括超級管理員），留言，評論。本項目的關(guān)系有：留言與評論間的一對多關(guān)系。進一步，數(shù)據(jù)庫各表的設(shè)計如下：管理員表（TAdmin）ID int 管理員ID NotNull 主鍵，自增Name varchar(20) 登錄名 NotNullPassword varchar(50) 登錄密碼 NotNull 使用MD5加密留言表（TMessage）ID int 留言ID NotNull 主鍵，自增GuestName varchar(20) 留言者用戶名 NotNullGuestEmail varchar(100) 留言者E-mail NullContent text 留言內(nèi)容 Not

7、NullTime datetime 發(fā)表留言時間 NotNull Reply text 回復 NullIsPass varchar(10) 是否通過驗證 NotNull評論表（TComment）ID int 評論ID NotNull 主鍵，自增Content text 評論內(nèi)容 NotNullTime datetime 發(fā)表評論時間 NotNullMessageID int 所屬留言的ID 外鍵基于.NET平臺的分層架構(gòu)實戰(zhàn)（三）架構(gòu)概要設(shè)計本文主要是對將要實現(xiàn)的架構(gòu)進行一個總體的描述，使朋友們對這個架構(gòu)有個宏觀上的認識。這篇文章理論性的東西會偏多一點，從下篇開始，將進行實際項目的開發(fā)。這篇文

8、章的許多內(nèi)容摘自我的畢業(yè)論文。架構(gòu)基本原則： 這里，將描述一些在這個架構(gòu)設(shè)計中的基本原則，其中很多都是經(jīng)典的設(shè)計原則，不過針對分層架構(gòu)的特點，用我自己的語言進行了描述。其中也有我自己提出的原則。逐層調(diào)用原則及單向調(diào)用原則現(xiàn)在約定將N層架構(gòu)的各層依次編號為1、2、K、N-1、N，其中層的編號越大，則越處在上層。那么，我們設(shè)計的架構(gòu)應該滿足以下兩個原則：1.第K（1K=N）層只準依賴第K-1層，而不可依賴其他底層。2.如果P層依賴Q層，則P的編號一定大于Q。其中第一個原則，保證了依賴的逐層性，及整個架構(gòu)的依賴是逐層向下的，而不能跨層依賴。第二個原則，則保證了依賴的單向性，及只能上層依賴底層，而不能

9、底層反過來依賴上層。針對接口編程，而不是針對實現(xiàn)編程這里所指的接口，不是特指編程語言中的具體語言元素（如C#中由Interface定義的語言接口），而是指一種抽象的，在語義層面上起著接合作用語義體。它的具體實現(xiàn)，可能是接口，可能是抽象類，甚至可能是具體類。我認為，從不同的視角，接口可以有以下兩種定義：1.接口是一組規(guī)則的集合，它規(guī)定了實現(xiàn)本接口的類或接口必須擁有的一組規(guī)則。體現(xiàn)了自然界“如果你是則必須能”的理念。2.接口是在一定粒度視圖上同類事物的抽象表示。注意這里我強調(diào)了在一定粒度視圖上，因為“同類事物”這個概念是相對的，它因為粒度視圖不同而不同。具體到N層架構(gòu)中，針對接口編程的意義在部分上

10、是這樣的：現(xiàn)仍約定將N層架構(gòu)的各層依次編號為1、2、K、N-1、N，其中層的編號越大，則越處在上層，那么第K層不應該依賴具體一個K-1層，而應該依賴一個K-1層的接口，即在第K層中不應該有K-1層中的某個具體類。依賴倒置原則在軟件設(shè)計原則中，有一種重要的思想叫做依賴倒置。它的核心思想是：不能讓高層組件依賴底層組件，而且，不管高層組件和底層組件，兩者都應依賴于抽象。那么，這個原則和我們上面的原則是否矛盾呢？其實并不矛盾。因為這個原則定義中的“依賴”是指“具體依賴”，而上面定義中的依賴全部指“抽象依賴”。我對這兩種依賴的定義如下：具體依賴如果P層中有一個或一個以上的地方實例化了Q層中某個具體類，則

11、說P層具體依賴于Q層。抽象依賴如果P層沒有實例化Q層中的具體類，而是在一個或一個以上的地方實例化了Q層中某個接口，則說P層抽象依賴于Q層，也叫接口依賴于Q層。從這兩個定義可以看到，所謂的依賴倒置原則，正是上面提到針對接口編程，而不是針對實現(xiàn)編程，兩者在本質(zhì)上是統(tǒng)一的。綜上所述，可以看出，本課題設(shè)計的分層架構(gòu)，應該是這樣一種架構(gòu)：1.N層架構(gòu)的各層依次編號為1、2、K、N-1、N，其中層的編號越大，則越處在上層。2.架構(gòu)中僅存在一種依賴，即第K層接口依賴第K-1層，其中1K=N。封裝變化原則封裝變化的原則定義為：找出應用中可能需要變化之處，把它們獨立出來，不要和那些不需要變化的代碼混雜在一起。開

12、放-關(guān)閉原則開發(fā)-關(guān)閉原則定義為：對擴展開放，對修改關(guān)閉。具體到N層架構(gòu)中，可以描述為：當某一層有了一個新的具體實現(xiàn)時，它應該可以在不修改其他層的情況下，與此新實現(xiàn)無縫連接，順利交互。單一歸屬原則在這個架構(gòu)中，任何一個操作類都應該有單一的職責，屬于單獨的一層，而不能同時擔負兩種職責或?qū)儆诙鄠€層次（實體類及輔助類可以被多個層使用，但它們不屬于任何一個層，而是獨立存在）。層次劃分：目前，典型的分層架構(gòu)是三層架構(gòu)，即自底向上依次是數(shù)據(jù)訪問層、業(yè)務邏輯層和表示層。這種經(jīng)典架構(gòu)經(jīng)歷了時間的考驗和實踐的多次檢驗，被認為是合理、有效的分層設(shè)計，所以，在本文中，將沿襲這種經(jīng)典架構(gòu)，使用數(shù)據(jù)訪問層、業(yè)務邏輯層和

13、表示層的三層架構(gòu)體系。職責劃分：目前，在典型的三層架構(gòu)中，對層次各自的職責劃分并沒有一個統(tǒng)一的規(guī)范，綜合現(xiàn)有的成功實踐和.NET平臺的特殊性，在本文中將三層架構(gòu)的職責劃分如下：數(shù)據(jù)訪問層負責與數(shù)據(jù)源的交互，即數(shù)據(jù)的插入、刪除、修改以及從數(shù)據(jù)庫中讀出數(shù)據(jù)等操作。對數(shù)據(jù)的正確性和有效性不負責，對數(shù)據(jù)的用途不了解，不負擔任何業(yè)務邏輯。業(yè)務邏輯層負責系統(tǒng)領(lǐng)域業(yè)務的處理，負責邏輯性數(shù)據(jù)的生成、處理及轉(zhuǎn)換。對流入的邏輯性數(shù)據(jù)的正確性及有效性負責，對流出的邏輯性數(shù)據(jù)及用戶性數(shù)據(jù)不負責，對數(shù)據(jù)的呈現(xiàn)樣式不負責。表示層負責接收用戶的輸入、將輸出呈現(xiàn)給用戶以及訪問安全性驗證。對流入的數(shù)據(jù)的正確性和有效性負責，對呈

14、現(xiàn)樣式負責，對流出的數(shù)據(jù)正確性不負責，但負責在數(shù)據(jù)不正確時給出相應的異常信息。模塊劃分及交互設(shè)計：綜合以上分析，可在宏觀上將整個系統(tǒng)分為一下幾個模塊：實體類模塊一組實體類的集合，負責整個系統(tǒng)中數(shù)據(jù)的封裝及傳遞。數(shù)據(jù)訪問層接口族一組接口的集合，表示數(shù)據(jù)訪問層的接口。業(yè)務邏輯層接口族一組接口的集合，表示業(yè)務邏輯層的接口。數(shù)據(jù)訪問層模塊一組類的集合，完成數(shù)據(jù)訪問層的具體功能，實現(xiàn)數(shù)據(jù)訪問層接口族。業(yè)務邏輯層模塊一組類的集合，完成業(yè)務邏輯層的具體功能，實現(xiàn)業(yè)務邏輯層接口族。表示層模塊程序及可視元素的集合，負責完成表示層的具體功能。IoC容器模塊負責依賴注入的實現(xiàn)。輔助類模塊完成全局輔助性功能。各模塊見

15、交互關(guān)系如下：這篇中理論比較多，但是它是整個架構(gòu)的基礎(chǔ)，可以幫助朋友們對將要實現(xiàn)的項目架構(gòu)及要遵循的原則有一個整體的了解。當然，在后續(xù)文章中，將主要討論Demo項目的實際開發(fā)過程，那時，這些思想和理論性的東西將得到體現(xiàn)?；?NET平臺的分層架構(gòu)實戰(zhàn)（四）實體類的設(shè)計與實現(xiàn)實體類是現(xiàn)實實體在計算機中的表示。它貫穿于整個架構(gòu)，負擔著在各層次及模塊間傳遞數(shù)據(jù)的職責。一般來說，實體類可以分為“貧血實體類”和“充血實體類”，前者僅僅保存實體的屬性，而后者還包含一些實體間的關(guān)系與邏輯。我們在這個Demo中用的實體類將是“貧血實體類”。 大多情況下，實體類和數(shù)據(jù)庫中的表（這里指實體表，不包括表示多對多對應

16、的關(guān)系表）是一一對應的，但這并不是一個限制，在復雜的數(shù)據(jù)庫設(shè)計中，有可能出現(xiàn)一個實體類對應多個表，或者交叉對應的情況。在本文的Demo中，實體類和表是一一對應的，并且實體類中的屬性和表中的字段也是對應的。在看實體類的代碼前，先看一下系統(tǒng)的工程結(jié)構(gòu)。如上圖所示，在初始階段，整個系統(tǒng)包括6個工程，它們的職責是這樣的：Web表示層Entity存放實體類Factory存放和依賴注入及IoC相關(guān)的類IBLL存放業(yè)務邏輯層接口族IDAL存放數(shù)據(jù)訪問層接口族Utility存放各種工具類及輔助類這只是一個初期架構(gòu)，主要是將整個系統(tǒng)搭一個框架，在后續(xù)開發(fā)中，將會有其他工程被陸陸續(xù)續(xù)添加進來。我們的實體類將放在E

17、ntity工程下，這里包括三個文件：AdminInfo.cs，MessageInfo.cs，CommentInfo.cs，分別是管理員實體類、留言實體類和評論實體類。具體代碼如下：AdminInfo.cs:AdminInfo1using System;23namespace NGuestBook.Entity45 /*/ 6 / 實體類-管理員7 / 8 Serializable9 public class AdminInfo10 11 private int id;12 private string name;13 private string password;1415 public in

18、t ID16 17 get return this.id; 18 set this.id = value; 19 2021 public string Name22 23 get return ; 24 set = value; 25 2627 public string Password28 29 get return this.password; 30 set this.password = value; 31 32 3334MessageInfo.cs:MessageInfo1using System;23namespace NGuestBook.E

19、ntity45 /*/ 6 / 實體類-留言7 / 8 Serializable9 public class MessageInfo10 11 private int id;12 private string guestName;13 private string guestEmail;14 private string content;15 private DateTime time;16 private string reply;17 private string isPass;1819 public int ID20 21 get return this.id; 22 set this.

20、id = value; 23 2425 public string GuestName26 27 get return this.guestName; 28 set this.guestName = value; 29 3031 public string GuestEmail32 33 get return this.guestEmail; 34 set this.guestEmail = value; 35 3637 public string Content38 39 get return this.content; 40 set this.content = value; 41 424

21、3 public DateTime Time44 45 get return this.time; 46 set this.time = value; 47 4849 public string Reply50 51 get return this.reply; 52 set this.reply = value; 53 5455 public string IsPass56 57 get return this.isPass; 58 set this.isPass = value; 59 60 6162CommentInfo.cs:CommentInfo1using System;23nam

22、espace NGuestBook.Entity45 /*/ 6 / 實體類-評論7 / 8 Serializable9 public class CommentInfo10 11 private int id;12 private string content;13 private DateTime time;14 private int message;1516 public int ID17 18 get return this.id; 19 set this.id = value; 20 2122 public string Content23 24 get return this.c

23、ontent; 25 set this.content = value; 26 2728 public DateTime Time29 30 get return this.time; 31 set this.time = value; 32 3334 public int Message35 36 get return this.message; 37 set this.message = value; 38 39 4041大家可以看出，實體類的代碼很簡單，僅僅是負責實體的表示和數(shù)據(jù)的傳遞，不包含任何邏輯性內(nèi)容。下篇將介紹接口的設(shè)計。 基于.NET平臺的分層架構(gòu)實戰(zhàn)（五）接口的設(shè)計與實現(xiàn)接下

24、來，將進行接口的設(shè)計。這里包括數(shù)據(jù)訪問層接口和業(yè)務邏輯層接口。在分層架構(gòu)中，接口扮演著非常重要的角色，它不但直接決定了各層中的各個操作類需要實現(xiàn)何種操作，而且它明確了各個層次的職責。接口也是系統(tǒng)實現(xiàn)依賴注入機制不可缺少的部分。本項目的接口設(shè)計將按如下順序進行：1.首先由前文的需求分析，列出主要的UI部分。2.分析各個UI需要什么業(yè)務邏輯支持，從而確定業(yè)務邏輯層接口。3.分析業(yè)務邏輯層接口需要何種數(shù)據(jù)訪問操作，從而確定數(shù)據(jù)訪問層接口。另外，為保證完全的面向?qū)ο筇匦?，接口之間的數(shù)據(jù)傳遞主要靠實體類或?qū)嶓w類集合，禁止使用DataTable等對象傳遞數(shù)據(jù)。由需求分析，列出主要UI需求分析部分，請參看基

25、于.NET平臺的分層架構(gòu)實戰(zhàn)（二）需求分析與數(shù)據(jù)庫設(shè)計 。有需求分析，可以列出系統(tǒng)中主要應包括以下UI：UI01主頁面，列出全部的留言及相應評論，支持分頁顯示。留言按發(fā)表時間逆序顯示，評論緊跟在相應留言下。管理員可以通過相應鏈接對留言執(zhí)行通過驗證、刪除、回復以及對評論進行刪除操作。游客可通過相應連接進入發(fā)表留言評論頁面。UI02發(fā)表留言頁面，供游客發(fā)表新留言。UI03發(fā)表評論頁面，供游客發(fā)表評論。UI04回復留言頁面，供管理員回復留言。UI05管理員登錄頁面。UI06管理員修改個人密碼的頁面。UI07超級管理員登錄后的頁面，主要提供管理員列表?？梢酝ㄟ^相應鏈接將指定管理員刪除。UI08添加新管

26、理員的頁面。UI09操作成功完成后的跳轉(zhuǎn)提示頁面。UI10系統(tǒng)出現(xiàn)異常時顯示友好出錯信息的頁面。由UI識別業(yè)務邏輯操作UI01：按分頁取得留言，按指定留言取得全部評論，將指定留言通過驗證，將指定留言刪除，將指定評論刪除UI02：添加新留言UI03：添加新評論UI04：回復留言UI05：管理員登錄UI06：修改管理員密碼UI07：取得全部管理員信息，刪除管理員UI08：添加新管理員經(jīng)過整理，可得以下接口操作：IAdminBLL：Add（添加管理員），Remove（刪除管理員），ChangePassword（修改管理員密碼），Login（管理員登錄），GetAll（取得全部管理員）IMessage

27、BLL：Add（添加留言），Remove（刪除留言），Revert（回復留言），Pass（將留言通過驗證），GetByPage（按分頁取得留言）ICommentBLL：Add（添加評論），Remove（刪除評論），GetByMessage（按留言取得全部評論）這三個接口文件都放在IBLL工程下，具體代碼如下：IAdminBLL.cs:IAdminBLL1using System;2using System.Collections.Generic;3using System.Text;4using NGuestBook.Entity;56namespace NGuestBook.IBLL78 /

28、*/ 9 / 業(yè)務邏輯層接口-管理員10 / 11 public interface IAdminBLL12 13 /*/ 14 / 添加管理員15 / 16 / 新管理員實體類17 / 是否成功18 bool Add(AdminInfo admin);1920 /*/ 21 / 刪除管理員22 / 23 / 欲刪除的管理員的ID24 / 是否成功25 bool Remove(int id);2627 /*/ 28 / 修改管理員密碼29 / 30 / 欲修改密碼的管理員的ID31 / 新密碼32 / 是否成功33 bool ChangePassword(int id,string passw

29、ord);3435 /*/ 36 / 管理員登錄37 / 38 / 管理員登錄名39 / 管理員密碼40 / 如果登錄成功，則返回相應管理員的實體類，否則返回null41 AdminInfo Login(string name,string password);4243 /*/ 44 / 取得全部管理員信息45 / 46 / 管理員實體類集合47 IList GetAll();48 49IMessageBLL.cs:IMessageBLL1using System;2using System.Collections.Generic;3using System.Text;4using NGues

30、tBook.Entity;56namespace NGuestBook.IBLL78 /*/ 9 / 業(yè)務邏輯層接口-留言10 / 11 public interface IMessageBLL12 13 /*/ 14 / 添加留言15 / 16 / 新留言實體類17 / 是否成功18 bool Add(MessageInfo message);1920 /*/ 21 / 刪除留言22 / 23 / 欲刪除的留言的ID24 / 是否成功25 bool Remove(int id);2627 /*/ 28 / 回復留言29 / 30 / 要回復的留言的ID31 / 回復信息32 / 是否成功33

31、 bool Revert(int id, string reply);3435 /*/ 36 / 將留言通過驗證37 / 38 / 通過驗證的留言的ID39 / 是否成功40 bool Pass(int id);4142 /*/ 43 / 按分頁取得留言信息44 / 45 / 每頁顯示幾條留言46 / 當前頁碼47 / 留言實體類集合48 IList GetByPage(int pageSize,int pageNumber);49 50ICommentBLL.csICommentBLL1using System;2using System.Collections.Generic;3using

32、 System.Text;4using NGuestBook.Entity;56namespace NGuestBook.IBLL78 /*/ 9 / 業(yè)務邏輯層接口-評論10 / 11 public interface ICommentBLL12 13 /*/ 14 / 添加評論15 / 16 / 新評論實體類17 / 是否成功18 bool Add(CommentInfo comment);1920 /*/ 21 / 刪除評論22 / 23 / 欲刪除的評論的ID24 / 是否成功25 bool Remove(int id);2627 /*/ 28 / 取得指定留言的全部評論29 / 30

33、 / 指定留言的ID31 / 評論實體類集合32 IList GetByMessage(int messageId);33 34由業(yè)務邏輯確定數(shù)據(jù)訪問操作IAdminBLL需要的數(shù)據(jù)訪問操作：插入管理員，刪除管理員，更新管理員信息，按ID取得管理員信息，按登錄名與密碼取得管理員，取得全部管理員IMessageBLL需要的數(shù)據(jù)訪問操作：插入留言，刪除留言，更新留言信息，按ID取得留言信息，按分頁取得留言ICommentBLL需要的數(shù)據(jù)訪問操作：插入評論，刪除評論，按留言取得全部評論另外，添加管理員時需要驗證是否存在同名管理員，所以需要添加一個“按登錄名取得管理員”。對以上操作進行整理，的如下接口

34、操作：IAdminDAL：Insert，Delete，Update，GetByID，GetByNameAndPassword，GetAllIMessageDAL：Insert，Delete，Update，GetByID，GetByPageICommentDAL：Insert，Delete，GetByMessage這三個接口文件放在IDAL工程下，具體代碼如下：IAdminDAL.cs：IAdminDAL1using System;2using System.Collections.Generic;3using System.Text;4using NGuestBook.Entity;56nam

35、espace NGuestBook.IDAL78 /*/ 9 / 數(shù)據(jù)訪問層接口-管理員10 / 11 public interface IAdminDAL12 13 /*/ 14 / 插入管理員15 / 16 / 管理員實體類17 / 是否成功18 bool Insert(AdminInfo admin);1920 /*/ 21 / 刪除管理員22 / 23 / 欲刪除的管理員的ID24 / 是否成功25 bool Delete(int id);2627 /*/ 28 / 更新管理員信息29 / 30 / 管理員實體類31 / 是否成功32 bool Update(AdminInfo adm

36、in);3334 /*/ 35 / 按ID取得管理員信息36 / 37 / 管理員ID38 / 管理員實體類39 AdminInfo GetByID(int id);4041 /*/ 42 / 按管理員名取得管理員信息43 / 44 / 管理員名45 / 管理員實體類46 AdminInfo GetByName(string name);4748 /*/ 49 / 按用戶名及密碼取得管理員信息50 / 51 / 用戶名52 / 密碼53 / 管理員實體類，不存在時返回null54 AdminInfo GetByNameAndPassword(string name,string passwor

37、d);5556 /*/ 57 / 取得全部管理員信息58 / 59 / 管理員實體類集合60 IList GetAll();61 62IMessageDAL.cs：IMessageDAL1using System;2using System.Collections.Generic;3using System.Text;4using NGuestBook.Entity;56namespace NGuestBook.IDAL78 /*/ 9 / 數(shù)據(jù)訪問層接口-留言10 / 11 public interface IMessageDAL12 13 /*/ 14 / 插入留言15 / 16 / 留言

38、實體類17 / 是否成功18 bool Insert(MessageInfo message);1920 /*/ 21 / 刪除留言22 / 23 / 欲刪除的留言的ID24 / 是否成功25 bool Delete(int id);2627 /*/ 28 / 更新留言信息29 / 30 / 留言實體類31 / 是否成功32 bool Update(MessageInfo message);3334 /*/ 35 / 按ID取得留言信息36 / 37 / 留言ID38 / 留言實體類39 MessageInfo GetByID(int id);4041 /*/ 42 / 按分頁取得留言信息43

39、 / 44 / 每頁顯示幾條留言45 / 當前頁碼46 / 留言實體類集合47 IList GetByPage(int pageSize,int pageNumber);48 49ICommentDAL.cs：ICommentDAL1using System;2using System.Collections.Generic;3using System.Text;4using NGuestBook.Entity;56namespace NGuestBook.IDAL78 /*/ 9 / 數(shù)據(jù)訪問層接口-評論10 / 11 public interface ICommentDAL12 13 /*

40、/ 14 / 插入評論15 / 16 / 評論實體類17 / 是否成功18 bool Insert(CommentInfo comment);1920 /*/ 21 / 刪除評論22 / 23 / 欲刪除的評論的ID24 / 是否成功25 bool Delete(int id);2627 /*/ 28 / 取得指定留言的全部評論29 / 30 / 指定留言的ID31 / 評論實體類集合32 IList GetByMessage(int messageId);33 34基于.NET平臺的分層架構(gòu)實戰(zhàn)（六）依賴注入機制及IoC的設(shè)計與實現(xiàn)我們設(shè)計的分層架構(gòu)，層與層之間應該是松散耦合的。因為是單向單

41、一調(diào)用，所以，這里的“松散耦合”實際是指上層類不能具體依賴于下層類，而應該依賴于下層提供的一個接口。這樣，上層類不能直接實例化下層中的類，而只持有接口，至于接口所指變量最終究竟是哪一個類，則由依賴注入機制決定。 之所以這樣做，是為了實現(xiàn)層與層之間的“可替換”式設(shè)計，例如，現(xiàn)在需要換一種方式實現(xiàn)數(shù)據(jù)訪問層，只要這個實現(xiàn)遵循了前面定義的數(shù)據(jù)訪問層接口，業(yè)務邏輯層和表示層不需要做任何改動，只需要改一下配置文件系統(tǒng)即可正常運行。另外，基于這種結(jié)構(gòu)的系統(tǒng)，還可以實現(xiàn)并行開發(fā)。即不同開發(fā)人員可以專注于自己的層次，只有接口被定義好了，開發(fā)出來的東西就可以無縫連接。 在J2EE平臺上，主要使用Spring框架

42、實現(xiàn)依賴注入。這里，我們將自己做一個依賴注入容器。 依賴注入的理論基礎(chǔ)是Abstract Factory設(shè)計模式，這里結(jié)合具體實例簡單介紹一下。上圖以數(shù)據(jù)訪問層為例，展示了Abstract Factory模式的應用。如圖，現(xiàn)假設(shè)有針對Access和SQLServer兩種數(shù)據(jù)庫的數(shù)據(jù)訪問層，它們都實現(xiàn)了數(shù)據(jù)訪問層接口。每個數(shù)據(jù)訪問層有自己的工廠，所有工廠都實現(xiàn)自IDALFactory接口。而客戶類（這里就是業(yè)務邏輯層類）僅與工廠接口、數(shù)據(jù)訪問層接口耦合，而與具體類無關(guān)，這樣，只要通過配置文件確定實例化哪個工廠，就可以得到不同的數(shù)據(jù)訪問層。然而，這種設(shè)計雖然可行，但是代碼比較冗余，因為這樣需要為數(shù)據(jù)訪問層的每一個實現(xiàn)編寫一個工廠，業(yè)務邏輯層也一樣。在以前，我們毫無辦法，但是，.NET平臺引入的反射機制，給我們提供了一種解