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

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

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

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

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

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

6、實體有：管理員（不包括超級管理員），留言，評論。本項目的關系有：留言與評論間的一對多關系。進一步，數據庫各表的設計如下：管理員表（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 留言內容 Not

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

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

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

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

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

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

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

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

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

16、的關系表）是一一對應的，但這并不是一個限制，在復雜的數據庫設計中，有可能出現一個實體類對應多個表，或者交叉對應的情況。在本文的Demo中，實體類和表是一一對應的，并且實體類中的屬性和表中的字段也是對應的。在看實體類的代碼前，先看一下系統的工程結構。如上圖所示，在初始階段，整個系統包括6個工程，它們的職責是這樣的：Web表示層Entity存放實體類Factory存放和依賴注入及IoC相關的類IBLL存放業(yè)務邏輯層接口族IDAL存放數據訪問層接口族Utility存放各種工具類及輔助類這只是一個初期架構，主要是將整個系統搭一個框架，在后續(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大家可以看出，實體類的代碼很簡單，僅僅是負責實體的表示和數據的傳遞，不包含任何邏輯性內容。下篇將介紹接口的設計。 基于.NET平臺的分層架構實戰(zhàn)（五）接口的設計與實現接下

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

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

26、理員的頁面。UI09操作成功完成后的跳轉提示頁面。UI10系統出現異常時顯示友好出錯信息的頁面。由UI識別業(yè)務邏輯操作UI01：按分頁取得留言，按指定留言取得全部評論，將指定留言通過驗證，將指定留言刪除，將指定評論刪除UI02：添加新留言UI03：添加新評論UI04：回復留言UI05：管理員登錄UI06：修改管理員密碼UI07：取得全部管理員信息，刪除管理員UI08：添加新管理員經過整理，可得以下接口操作：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è)務邏輯確定數據訪問操作IAdminBLL需要的數據訪問操作：插入管理員，刪除管理員，更新管理員信息，按ID取得管理員信息，按登錄名與密碼取得管理員，取得全部管理員IMessageBLL需要的數據訪問操作：插入留言，刪除留言，更新留言信息，按ID取得留言信息，按分頁取得留言ICommentBLL需要的數據訪問操作：插入評論，刪除評論，按留言取得全部評論另外，添加管理員時需要驗證是否存在同名管理員，所以需要添加一個“按登錄名取得管理員”。對以上操作進行整理，的如下接口

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 / 數據訪問層接口-管理員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 / 數據訪問層接口-留言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 / 數據訪問層接口-評論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平臺的分層架構實戰(zhàn)（六）依賴注入機制及IoC的設計與實現我們設計的分層架構，層與層之間應該是松散耦合的。因為是單向單

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

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