在進行cs細節分析的之前，有必要先了解cs工程（解決方案）的組成，以及組成cs工程中項目的結構，本文分為三個部分：1、工程結構 2、三層構架 3、數據庫構架。

1：工程結構

cs工程主要分為4個部分

a：系統底層構架項目communityservercomponents、communityservercontrols，提供給其他項目父類、接口、全局變量、cs系統設置、公用用戶自定義控件、用戶與權限管理業務邏輯、異常處理等。

b：communityserverblogs、communityserverforums、communityservergalleries、communityserverdocuments、communityserverguestbook。這些項目都是通過繼承、調用全局方法等實現自己的業務邏輯并且抽象出自己的data provider，業務邏輯不同，但項目都是采用三層結構。

c：ui項目，這里指communityserverweb。該項目中幾乎不包含邏輯代碼，只是簡單的html與對運用項目中的skin（skin是 *.ascx文件，但沒有關聯相應的*.cs，大致可以這樣理解：如communityserverblogs 中的skin 文件*.ascx相關聯的*.cs邏輯代碼在communityserverblogs項目中實現，并且不保存在與*.ascx文件相同的目錄下，而是與communityserverblogs中其他業務邏輯一起編譯為communityserver.blogs.dll）。同時ui項目中還保存了languages文件與一些配置文件等。

d：dataprovider，目前只實現了sqldataprovider，對sql server數據庫進行操作。dataprovider實際上是對b部分中實體項目數據庫操作抽象的具體實現。數據操作的provider方式帶來幾個好處，不關心具體實現、支持多數據庫、有利于團隊協作分工等。

2、三層構架

在communityserverblogs、communityserverforums、communityservergalleries等幾個項目中都采用了三層構架，如下圖：

業務邏輯是穿插在contorls與components中，在單獨的一個項目中contorls與components體現在namespace里，下面以communityservergalleries項目為例講述一下具體項目的三層結構：

為了便于文件的管理，項目中建立了components與contorls文件夾分別存放名字空間為communityserver.galleries.components與communityserver.galleries.controls。如果你是一個初學者或者對三層結構不是太了解，可能很多時候你會對三層構架感到困惑，其實這個層的概念沒有絕對的劃分界限，更不是用類作為最小的單位。這種劃分是相對的，是一種為編寫代碼功能的劃分。communityservergalleries項目中沒有直接編寫對數據庫的操作代碼，而是使用了provider的方式把操作的方法進行抽象：

例：public abstract hashtable getgalleries(bool mergepermissions);

抽象后的代碼可以和普通方法一樣被業務邏輯調用，由于使用了provider的方式，使得數據層與業務層之間是松散耦合的，可以很容易的進行數據庫更換（只需要更換對抽象數據操作類的具體實現方法，而不會影響到業務邏輯層的代碼）。

業務邏輯包括幾個部分：communityserver.galleries.components下所有的實體類，這些實體類大多數通過繼承post、ithread、permissionbase等在communityservercomponents項目中定義過或者申明過的類與接口。communityserver.galleries命名空間下的一些類，這些類用來處理業務邏輯運行過程中的數據，同時進行緩存和過濾等操作（過濾操作是通過在communityservercomponents項目中的csapplication.cs類下定義委托與事件完成的，要理解這個過程需要對cs有一定的了解，后續我會做一個cs中委托與事件的專題）。還有一部分業務邏輯混淆在communityserver.galleries.controls命名空間下的一些類中，他們與ui表示層較為緊密，你很難準確的定義他們是屬于業務邏輯還是表現層代碼。

cs中表示層中的類大致可以分為三部分，1：是需要*.ascx的直接處理用戶界面或者用戶輸入輸出的代碼，這些類都間接的繼承communityservercontrols項目中的templatedwebcontrol類。2：要進行換膚就少不了使用一些輔助的類，這些類提供一些基礎服務，如：找到*.cs文件對應*.ascx所在路徑等。3：是不需要*.ascx的用戶自定義控件，一般繼承自.net提供的webcontrols。這些類被放入controls/utility文件夾下面。

傳統的asp.net web頁面設計時在建立*.aspx或者*.ascx都會同時建立一個同名的*.cs文件，用來實現對頁面中控件的操作，頁面這個時候就像一個容器。通過codebehind頁面在運行時會自動找到對應的類(這個過程如何實現沒有去分析過，但是我們可以通過反射達到同樣的效果，同時可以獲得更高的靈活性)。cs系統中的ui就是通過反射尋找到*.ascx對應的類從而實現相應的ui處理函數，而*.ascx只要保持名稱和內容中控件的id不變，具體html代碼如何更換并不影響到整個系統的功能，cs系統也正是通過這樣的手段達到換膚的目的，同時加入masterpage又可以減少html代碼中重復部分。最后html與css樣式表的結合你就可以很容易改變網站的皮膚的樣式，包括文字樣子和div的布局了。*.cs與*.ascx文件剝離后網站美工與程序設計人員就真正的分開了，有利于團隊協作，發揮個人特長。

還有一點必須說明：在cs項目中很多*.aspx文件只是一個加入了masterpage的框架頁，甚至是一個什么都沒有的空文件（如多數default.aspx頁面），框架文件中嵌入了大量的類似于“<galleries:galleryadmin id="galleryadmin" runat="server" />”這樣的控件，其實這個控件對應于skin-galleryadmin.ascx的皮膚。如果你能理解到這里，想看明白cs的大部分代碼應該不會有問題。

3、數據庫構架

先看一下dataprovider模型：

模型中可以看出抽象的dataprovider是與具體的數據庫操作dataprovider分離的，在cs中components與抽象的dataprovider被編譯在一個項目中，而sql server dataprovider則被單獨的編譯出來。好處都可以看到那就是更換不同的dataprovider抽象實現不同的數據庫操作，另外這種松散耦合的方式有利于團隊開放。如何實現這樣的dataprovider方式呢（我這里簡述一些，具體的請關注后續的專題）？

先看抽象類，抽象類被存放在相應項目的providers目錄下，以gallery項目為例子，它的命名空間是communityserver.galleries.components

整個類都是public abstract class，這個很好理解，其實關鍵的是在“instance”

部分，在 instance里通過調用communityservercomponents項目dataproviders.cs類中的createinstance方法初始化一個gallerydataprovider。

過程是先在communityserver.config文件中找到

public static readonly string gallerydataprovidername = "gallerydataprovider";

中的“gallerydataprovider”，這里為：

<add  name = "gallerydataprovider" type = "communityserver.data.gallerysqldataprovider, communityserver.sqldataprovider" connectionstringname = "sitesqlserver" databaseownerstringname = "sitesqlserverowner"    />

根據“type”中的內容，運用type.gettype與activator.createinstance把communityserver.sqldataprovider.dll程序集中對應的communityserver.data.gallerysqldataprovider類實例化，實例化后類似gallerydataprovider.instance().getgalleries(true)的調用其實就是直接操作communityserver.sqldataprovider.dll程序集中communityserver.data.gallerysqldataprovider類下的

public override hashtable getgalleries(bool mergepermissions)方法。這個過程可能比較難理解，但是理解只是時間問題。

數據訪問層的中與數據庫最緊密接觸的就是sqldataprovider（sqldataprovider是對sql server數據庫操作抽象的實現，你也可以對其他數據庫進行抽象實現，目前cs只提供sql server實現），在sqldataprovider里使用的是對存儲過程的操作而沒有使用sql text。在前一片專題中我寫過這個做的好處，這里不再多說。主要說明的是對數據的緩存與序化：

緩存：我個人習慣是把緩存寫在數據層里，而cs是把緩存管理寫在業務邏輯層中，而且緩存的數量是很大的，如對communityservergalleries項目中的讀取單個gallery方法：

public static gallery getgallery(string applicationkey, bool cacheable)

一般的做法是為這個方法寫一個存儲過程，然后當有數據操作的時候從數據庫中調用相關數據，同時根據參數是否緩存數據，這看起來很好。我也總是覺得內存寶貴，能少緩存一點就少緩存一點，但是cs的做法是把全部gallery讀入hashtable，緩存掉！要讀取單個gallery的時候從緩存中找，根本不去管數據庫，更不要寫存儲過程（這倒是很方便）。當然了，cs中是對緩存定義了時間的。時間到期后緩存就自動被釋放了，但是在緩存釋放之前新的數據是不會被顯示出來的，對于一些更新不是很快的數據集來說這算是一種比較好的解決方案（在sql 2005中有更好的緩存解決方法，可以在新數據更新時更新緩存）。

數據序化：開發過crm的朋友應該都有體會，很多字段需要預留在數據庫中，因為你不了解使用crm系統的客戶會有一些什么樣的存儲要求，如：crm用戶需要保存他客戶的年齡，但是crm系統設計過程中不可能為這樣一個問題特意的加入這個存儲字段，通常的做法是給一些空字段，用戶使用的時候相應的對他進行初始化。但是導致的結果就是crm的數據庫慘不忍睹。更可怕的是，如果要進行軟件升級的時候如果需要添加一些原本沒有的字段，非常的麻煩，從實體類到數據庫操作的存儲過程都需要更改。而數據序化可以解決這個問題，其實當我第一次看到cs這種做法的時候是非常興奮的：第一，實現了添加字段不需要重新寫數據操作類，更不需要對相關的存儲過程進行修改。第二，存儲的字段很工整，全部值都保存在兩個字段中，如圖：

先分析一下存儲的數據，首先是propertynames字段，“enablecomments:s:0:4:moderatecomments:s:4:5:enableratings:s:9:4:” “enablecomments”其實是在實體類中定義的一個屬性名稱，“：”表示定義完畢，“s:0:4”表示在propertyvalues字段中的字符從0開始后面4位屬于“enablecomments”的屬性值，同理：“s:4:5”表示，從第四個字符開始，后面5個表示“moderatecomments”的屬性值，以此類推可以獲得propertynames所有的字段的值。（記得在asp.net forums時數據的序化是用binary存儲的，在cs中改為ntext可以對其進行搜索，解決序化后的數據搜索不便的問題。），關于如何進行序化等后續專題加以敘述。

在cs的最底層就是數據庫和存儲過程了，關鍵的幾個表cs_groups、cs_sections、cs_threads和cs_posts表分別對應于communtyserver.components命名空間下的group、section、thread和post類，groups是分組，對應論壇來說就是“板塊組”、版塊”、“線索”和“帖子”，對應于blog就是“博客分組”、“博客”“線索”、“隨筆或者文章”。這個cs_threads有點難理解，其實它是對相應section下的post相關信息的統計與跟蹤，如最后回帖時間、評論總數等等。

上面大致分析了community server項目的體系結構，細節部分會在后續的專題中一一的分析。不管怎么說community server是一個相對龐大的工程，要完全的講解與系統的分析還需要很多的文字。