【正文】 設計中，有可能出現(xiàn)一個實體類對應多個表，或者交叉對應的情況。一般來說，實體類可以分為“貧血實體類”和“充血實體類”，前者僅僅保存實體的屬性，而后者還包含一些實體間的關系與邏輯。各模塊間交互關系如下：、總體架構圖（四）——實體類的設計與實現(xiàn) 實體類是現(xiàn)實實體在計算機中的表示。IoC容器模塊——負責依賴注入的實現(xiàn)。業(yè)務邏輯層模塊——一組類的集合，完成業(yè)務邏輯層的具體功能，實現(xiàn)業(yè)務邏輯層接口族。業(yè)務邏輯層接口族——一組接口的集合，表示業(yè)務邏輯層的接口。模塊劃分及交互設計：綜合以上分析，可在宏觀上將整個系統(tǒng)分為一下幾個模塊：實體類模塊——一組實體類的集合，負責整個系統(tǒng)中數(shù)據(jù)的封裝及傳遞。表示層——負責接收用戶的輸入、將輸出呈現(xiàn)給用戶以及訪問安全性驗證。業(yè)務邏輯層——負責系統(tǒng)領域業(yè)務的處理，負責邏輯性數(shù)據(jù)的生成、處理及轉換。職責劃分：目前，在典型的三層架構中，對層次各自的職責劃分并沒有一個統(tǒng)一的規(guī)范，在本文中將三層架構的職責劃分如下：數(shù)據(jù)訪問層——負責與數(shù)據(jù)源的交互，即數(shù)據(jù)的插入、刪除、修改以及從數(shù)據(jù)庫中讀出數(shù)據(jù)等操作。層次劃分：目前，典型的分層架構是三層架構，即自底向上依次是數(shù)據(jù)訪問層、業(yè)務邏輯層和表示層。具體到N層架構中，可以描述為：當某一層有了一個新的具體實現(xiàn)時，它應該可以在不修改其他層的情況下，與此新實現(xiàn)無縫連接，順利交互。封裝變化原則封裝變化的原則定義為：找出應用中可能需要變化之處，把它們獨立出來，不要和那些不需要變化的代碼混雜在一起。綜上所述，可以看出，本課題設計的分層架構，應該是這樣一種架構：、…、K、…、NN，其中層的編號越大，則越處在上層。抽象依賴——如果P層沒有實例化Q層中的具體類，而是在一個或一個以上的地方實例化了Q層中某個接口，則說P層抽象依賴于Q層，也叫接口依賴于Q層。因為這個原則定義中的“依賴”是指“具體依賴”，而上面定義中的依賴全部指“抽象依賴”。它的核心思想是：不能讓高層組件依賴底層組件，而且，不管高層組件和底層組件，兩者都應依賴于抽象。具體到N層架構中，針對接口編程的意義在部分上是這樣的：現(xiàn)仍約定將N層架構的各層依次編號為…、K、…、NN，其中層的編號越大，則越處在上層，那么第K層不應該依賴具體一個K1層，而應該依賴一個K1層的接口，即在第K層中不應該有K1層中的某個具體類。我認為，從不同的視角，接口可以有以下兩種定義：，它規(guī)定了實現(xiàn)本接口的類或接口必須擁有的一組規(guī)則。針對接口編程，而不是針對實現(xiàn)編程這里所指的接口，不是特指編程語言中的具體語言元素（如C中由Interface定義的語言接口），而是指一種抽象的，在語義層面上起著接合作用語義體。其中第一個原則，保證了依賴的逐層性，及整個架構的依賴是逐層向下的，而不能跨層依賴。那么，我們設計的架構應該滿足以下兩個原則：（1K=N）層只準依賴第K1層，而不可依賴其他底層。其中也有我自己提出的原則。這篇文章的許多內容摘自我的畢業(yè)論文。 外鍵（三）——架構概要設計 本文主要是對將要實現(xiàn)的架構進行一個總體的描述，使朋友們對這個架構有個宏觀上的認識。 int 發(fā)表評論時間 NotNullTime text NotNullint NotNull評論表（TComment）IDvarchar(10) NullIsPass text 發(fā)表留言時間 NotNullTime text 留言者Email NotNullGuestEmail varchar(20) NotNull int NotNull varchar(50) 登錄名 主鍵，自增Name 管理員ID進一步，數(shù)據(jù)庫各表的設計如下：管理員表（TAdmin）ID通過需求分析，可以觀察得出，本項目的實體有：管理員（不包括超級管理員），留言，評論。普通管理員可偶多個，負責對留言的管理，并可以修改自己的登錄密碼。，未通過驗證的留言不可以評論。需求分析：這個項目是一個留言本，其業(yè)務極為簡單，現(xiàn)將其描述如下。實際中，這個環(huán)節(jié)不但需要系統(tǒng)分析師、軟件工程師等計算機方面的專家，還需要相關領域的領域專家參與才能完成。這個文章系列不會對所用到的技術進行詳細講解，具體請參考相關文獻，閱讀文章前最好能對以下技術有一個了解：語言,Ajax AJAX框架（特別是客戶端編程）,CSS,標準化布局另外， ，（如LINQ、 MVC等）不會討論，IDE使用Visual Studio 2005，數(shù)據(jù)庫會用到SQLServer2005 Express和Access2003。為了讓朋友們把主要精力放在理解分層架構而不是案例本身，我準備選擇一個相對簡單的留言本系統(tǒng)作為Demo，這個系統(tǒng)的名字就叫做NGuestBook。然而，論文的理論性太強，不適合在網上發(fā)布，尤其不適合初學者理解，所以，我想在這個文章系列中，少講理論，而是通過做一個完整的案例來討論分層架構的基本方法，這樣會直觀很多。（一）——綜述 通過瀏覽博客園的文章發(fā)現(xiàn)，很多朋友對分層架構特別感興趣，（題目叫“”）。通過做這篇論文，我對分層架構有了一定的了解，所以，就萌發(fā)了想寫一個文章系列，詳述一下分層架構。希望在這個文章系列的寫作過程中，能和朋友們一起學習，一起進步。初步計劃將這個文章系列分為以下幾篇：——Access+動態(tài)生成SQL語言——SQLServer+存儲過程——基于NBear框架的ORM實現(xiàn)當然，以上只是初步計劃，在寫文章的過程中可能會根據(jù)具體情況適當調整，但是內容大體就是這些。（二）——需求分析與數(shù)據(jù)庫設計 在實際的項目中，需求分析和數(shù)據(jù)庫的設計是很重要的一個環(huán)節(jié)，這個環(huán)節(jié)會直接影響項目的開發(fā)過程和質量。但是，在這個文章系列中，所要使用的Demo僅僅是一個例子，而且其業(yè)務極為簡單，因此，這里并不是真正的需求分析和數(shù)據(jù)庫設計，而是將Demo的需求和數(shù)據(jù)庫羅列至此，使朋友們對Demo有一個大體的了解，方便后續(xù)文章中開發(fā)過程的理解。，留言完成后，不會立即顯示正文，而是要經過管理員驗證后才可顯示。（這個回復不同于評論，是直接顯示在正文下面，而且是一個留言只能有一個回復），并可對留言與評論實行刪除，以及對留言進行通過驗證操作。超級管理員只有一個，負責對普通管理員實行添加、刪除操作。這個項目的用例圖如下：、NGuestBook的用例圖數(shù)據(jù)庫設計：設計數(shù)據(jù)表之前，首先進行實體和關系的識別與確定。本項目的關系有：留言與評論間的一對多關系。 int NotNull varchar(20) NotNullPassword 登錄密碼 使用MD5加密留言表（TMessage）ID 留言ID 主鍵，自增GuestName 留言者用戶名 varchar(100) NullContent 留言內容 datetime NotNullReply 回復 是否通過驗證 評論ID 主鍵，自增Content 評論內容 datetime NotNullMessageID 所屬留言的ID這篇文章理論性的東西會偏多一點，從下篇開始，將進行實際項目的開發(fā)。架構基本原則：這里，將描述一些在這個架構設計中的基本原則，其中很多都是經典的設計原則，不過針對分層架構的特點，用我自己的語言進行了描述。逐層調用原則及單向調用原則現(xiàn)在約定將N層架構的各層依次編號為…、K、…、NN，其中層的編號越大，則越處在上層。，則P的編號一定大于Q。第二個原則，則保證了依賴的單向性，及只能上層依賴底層，而不能底層反過來依賴上層。它的具體實現(xiàn)，可能是接口，可能是抽象類，甚至可能是具體類。體現(xiàn)了自然界“如果你是……則必須能……”的理念。注意這里我強調了在一定粒度視圖上，因為“同類事物”這個概念是相對的，它因為粒度視圖不同而不同。依賴倒置原則在軟件設計原則中，有一種重要的思想叫做依賴倒置。那么，這個原則和我們上面的原則是否矛盾呢？其實并不矛盾。我對這兩種依賴的定義如下：具體依賴——如果P層中有一個或一個以上的地方實例化了Q層中某個具體類，則說P層具體依賴于Q層。從這兩個定義可以看到，所謂的依賴倒置原則，正是上面提到針對接口編程，而不是針對實現(xiàn)編程，兩者在本質上是統(tǒng)一的。，即第K層接口依賴第K1層，其中1K=N。開放關閉原則開發(fā)關閉原則定義為：對擴展開放，對修改關閉。單一歸屬原則在這個架構中，任何一個操作類都應該有單一的職責，屬于單獨的一層，而不能同時擔負兩種職責或屬于多個層次（實體類及輔助類可以被多個層使用，但它們不屬于任何一個層，而是獨立存在）。這種經典架構經歷了時間的考驗和實踐的多次檢驗，被認為是合理、有效的分層設計，所以，在本文中，將沿襲這種經典架構，使用數(shù)據(jù)訪問層、業(yè)務邏輯層和表示層的三層架構體系。對數(shù)據(jù)的正確性和有效性不負責，對數(shù)據(jù)的用途不了解，不負擔任何業(yè)務邏輯。對流入的邏輯性數(shù)據(jù)的正確性及有效性負責，對流出的邏輯性數(shù)據(jù)及用戶性數(shù)據(jù)不負責，對數(shù)據(jù)的呈現(xiàn)樣式不負責。對流入的數(shù)據(jù)的正確性和有效性負責，對呈現(xiàn)樣式負責，對流出的數(shù)據(jù)正確性不負責，但負責在數(shù)據(jù)不正確時給出相應的異常信息。數(shù)據(jù)訪問層接口族——一組接口的集合，表示數(shù)據(jù)訪問層的接口。數(shù)據(jù)訪問層模塊——一組類的集合，完成數(shù)據(jù)訪問層的具體功能，實現(xiàn)數(shù)據(jù)訪問層接口族。表示層模塊——程序及可視元素的集合，負責完成表示層的具體功能。輔助類模塊——完成全局輔助性功能。它貫穿于整個架構，負擔著在各層次及模塊間傳遞數(shù)據(jù)的職責。我們在這個Demo中用的實體類將是“貧血實體類”。在本文的Demo中，實體類和表是一一對應的，并且實體類中的屬性和表中的字段也是對應的。、工程結構圖如上圖所示，在初始階段，整個系統(tǒng)包括6個工程，它們的職責是這樣的：Web——表示層Entity——存放實體類Factory——存放和依賴注入及IoC相關的類IBLL——存放業(yè)務邏輯層接口族IDAL——存放數(shù)據(jù)訪問層接口族Utility——存放各種工具類及輔助類這只是一個初期架構，主要是將整個系統(tǒng)搭一個框架，在后續(xù)開發(fā)中，將會有其他工程被陸陸續(xù)續(xù)添加進來。具體代