前幾天我在我的Blog上發布了NGuestBook（點擊這里下載），得到了很多反饋，在這里非常感謝大家的關注和支持。一些朋友在E-mail中提到，這個NGuestBook和我那個系列文章《基于.NET平臺的分層架構實戰》中講的Demo有非常多不一樣的地方，問我能不能單獨寫一篇文章說明一下這個新NGuestBook的架構方式和實現相關的問題。
      所以我專門寫下這篇文章，對這個NGuestBook的架構體系和實現進行一個簡要的說明，希望本文的內容能對大家有所幫助。
      有兩點要特別說明：一是下面的內容中非正式的使用了UML包圖，這里用UML只是為了描述一種架構，而不是建模，所以可能有很多不符合UML標準的地方，還請海涵了，只要您能看懂大體的結構表示就好。二是一下的描述，特別是圖示，是以抽象架構工件為基本元素的，可能不會和源碼中的工程、文件、類嚴格對應，但是，應該能很容易分辨出抽象工件元素和具體工程、文件等元素的對應關系。

　　總體架構
      我們先來看NGuestBook的總體架構圖，如圖1所示。

圖1

      整體采用分層架構，這個思想很明顯。從上到下依次為表示層（Web）、業務邏輯層（BusinessComponents）和數據訪問層（DataComponents）。
      其中表示層直接依賴業務邏輯層，而業務邏輯層通過數據訪問層接口依賴數據訪問層。在業務邏輯層和數據訪問層接口上，存在依賴注入組件（Factories），便于進行不同數據訪問層的替換。
      這里預設了三個數據訪問層，LinqDataComponents是使用linq to sql技術為ORM組件實現的數據訪問層，SQLDataComponents使用傳統的SQL語句訪問數據庫，這兩個數據訪問層都是以關系數據庫作為數據源；XMLDataComponents是以XML文件為數據源的數據訪問層，他們都是DataComponentInterfaces的實現。（特別說明：在提供的源代碼中，只實現了LinqDataComponents，其他兩個數據訪問層只給出了擴展接口，沒有具體實現。）
      Entities作為實體類組件，存放系統中用到的“貧血實體類”，這些實體類只用于存放數據，并負責在各層間數據的傳遞，是各層數據存取傳遞的媒介和標準。
      Utilities作為工具庫組件，存放各種可復用的工具類。
      下面，對各個組件分別進行說明。

　　實體類組件
      實體類組件是現實世界業務實體在計算機世界中的表示，負責在各層之間的數據的傳遞，并維護數據格式標準。說通俗一點，就是各個層都“認識”這組標準實體類，傳入、傳出數據都以這種格式進行。
      為什么要這樣呢？因為我們整體思想是盡可能保持各層間的耦合度較低，并相對獨立，但是系統要工作，各層間就不可避免交換數據，因此，我們需要一種標準的、簡單的、與各層無關的數據格式，否則如果強制某層強制其它層“認識”它特有的數據格式，就可能造成污染。
      例如，如果我們以DataTable為數據交換格式，那么業務邏輯層和表示層都得認識這種數據格式才行，如果有一天，我們要換數據訪問層，不需要DataTable了，那么業務邏輯層和表示層都要修改。所以，我們要使用這種標準的、與特定層無關的數據格式作為交換格式，而如果某層有特定的數據格式，要在內部實現轉換，對外傳遞的必須是這種標準格式。
      這里的實體類采用貧血實體類，而且由于業務很簡單，整個系統只有一個實體類：MessageInfo。

圖2

　　工具類組件
      工具類組件里是一些可復用的工具性類，這里主要包括三個：
      CacheAccessor：用于緩存的存取操作。
      SessionAccessor：用于Session的存取操作。
      ValidateHelper：用于數據驗證的相關操作，主要用在表示層里。

圖3

　　數據訪問層接口
      數據訪問層接口規定了數據訪問層應該實現的方法，并作為業務邏輯層的依賴接口。
      由于整體只有一個實體——Message需要數據持久化，所以數據訪問層接口只有一個接口文件。

圖4

　　基于linq to sql的數據訪問層
      NGuestBook實現的數據訪問層是基于linq to sql的。總體來說，開發小型項目時，linq to sql是不錯的ORM解決方案。數據訪問層的內部架構如圖5所示。

圖5

      其中DataClasses是linq to sql框架根據數據庫自動生成的特有實體類，用于linq to sql的操作。而數據訪問主部件MessageDataComponent僅僅依賴DataClasses，這是因為MessageDataComponent的linq to sql操作必須使用這種特殊的實體類。
      而對外交流時，又需要使用公共實體類MessageInfo，所以，我們需要一個EntityConvertor，作為兩種實體類之間的轉換器，這個轉換器是這個Linq to sql數據訪問層的內部機制，對外部一律透明。
      這里要注意，EntityConvertor是一個概念上的工件，實際實現時其功能集成于MessageDataComponent。

　　業務邏輯層
　　業務邏輯層實現主要業務。

　　業務邏輯層有兩個工件：AdminBusinessComponent和MessageBusinessComponent。其中后一個主要實現各種留言的業務操作，而前一個是管理員的業務操作。由于管理員的信息是記錄在配置文件中而非持久化在數據庫中，所以這個業務工件并不需要數據訪問層的支持。
      這里特別提醒，朋友們可以仔細看一下業務邏輯層的方法命名和代碼，就會明白，即使在如此微小的系統中，業務邏輯層也不是對數據訪問層簡單的封裝調用，業務邏輯和數據訪問是完全兩個不同的概念。

圖6

　　依賴注入組件
      依賴注入實現了依賴配置動態選擇數據訪問層并注入業務邏輯層中，實現兩層之間的解耦，具體實現的基礎是Abstract Factory模式，并配合了反射機制和緩存機制。

圖7

      如圖7所示，依賴注入組件的主要工件是DataComponentFactory，它是一個反射工廠，它可以通過反射機制加載某個指定的數據訪問層，而后將其注入到業務邏輯層中。至于具體加載哪一個，則依賴Web.config中的配置。
      兩外，它還依賴CacheAccessor實現緩存機制，對加載過的數據訪問組件進行緩存，提高系統運行效率。

　　表示層
     NGuestBook的表示層使用了Microsoft ASP.NET MVC框架，版本是Releasse Candidate，所以，整個表示層的架構符合MVC模式。

圖8

      由于ASP.NET MVC的架構原理非常復雜，這里就不將具體細節全部表述。大體架構如圖8所示，Controllers控制器組件是整個MVC的核心，負責整體的調控。而Views視圖組件則使用aspx頁面實現，Filters是一些攔截器類，主要實現了身份驗證和異常處理的功能。而Controllers直接依賴BusinessComponent完成業務功能，所以BusinessComponent實際上可以看成是MVC的Model。
      實際上，表示層還依賴工具類組件完成Session存取和數據驗證的工作。

　　總結
      以上就是NGuestBook架構的一個簡單說明，限于篇幅，不能完全顧及到每一個細節，還請見諒。希望以上內容對大家有所幫助。