--
discuz整體架構如下圖所示：
橫向表示
同一層次中涉及的各個模組(專案)
縱向表示
不同層次之間模組的關係，某些關係是如何在各層次中傳遞(穿越)
discuz架構上採用了比較流行的三層架構，即表現層，業務邏輯層，資料訪問層來進行設計，並結合自己的情況進行了特殊處理。
表現層：
表現層即為上圖中藍色虛線表示,主要包括:web，services，ui，control。各專案主要功能為：
ui 定義各種頁面基類，提供ajax訪問訪問介面。
control存放discuz用到的自定義伺服器端控制項。
services提供外部訪問介面。
discuz引入了一種模板引擎的機制，來實現表現層的多樣化。
主要設計思想為：針對設計人員，提供純靜態頁面，並提供了一套約定的語法和標籤（具體位置在：
templates
）。模板製作完成後，要進行模板匯入，此時discuz會將靜態模板進行解析將其轉換成 aspx頁面，然後放到aspx/1..n下。如果你開啟這下面的檔案，會發現前端只是乙個字串拼接的過程。要進行的邏輯判斷，都放到了後台**中。後台**只有乙份，所有的 aspx模板引用同乙個後台處理類。由此實現web表現的多樣化
當使用者進行頁面瀏覽時，首先確定顯示哪個模板，然後採用位址重寫技術，將其轉移到實際的處理檔案。在web.config配置為
可見discuz對所有的請求進行了控制，其**如下
（以index.aspx為例）：
首先程式會先查詢cookie，找到templateid，然後重定向到相應的模板檔案。
綜上所述：模板+重定向實現了表現層的多樣化。
業務邏輯層：
業務邏輯，顧名思義就是處理與業務相關的**。discuz採用的也是中小型專案的常用的「貧血模式」，即在業務邏輯層只是進行實體的獲取，**和賦值，幾乎沒有業務操作。
本該封裝在此層的業務**進行了分散，一部分前移至表現層（比如發帖時的加分操作，附件處理），一部分後移到了儲存過程（比如發帖後更新我的發帖列表）。
注：關於貧血模式的論述詳見 martin fowler
的相關著作
<
企業應用架構模
等
在業務層，使用了discuz快取。主要是更改了儲存體，將其儲存在xml中（為啥這麼喜歡用xml呢，印象中它是很慢的），呼叫方法和通常情況下幾乎無差別。
個人感覺其業務邏輯層是專案中設計最失敗的地方。拿發帖舉例,如果我進行設計，我的方案可能會是這樣：
時間關係，有時間再寫一篇文章。
順便說一句：如果要進行
discuz
的整合，主要呼叫的就是此層的**。
主要專案為：
discuz.forum
discuz.space
資料訪問層：
discuz基於商業考慮和版本限制等因素，迄今為止已有多種資料來源：access，mysql，sqlserver等。為了實現三種資料庫的介面統一，此處使用了介面和抽象類進行規範。
其類庫結構如下(呼叫方以post為例)：
各個資料庫中的postmanage都使用dbhelper進行通用資料庫的訪問。dbhelper本身並沒有指定具體的資料庫鏈結型別，引數型別，而是使用.net自帶的抽象類dbprovide***ctory來建立。具體資料庫的載入要等其靜態屬性provider,factory呼叫時，讀取配置檔案，以反射形式進行初始化。
**如下：
通過此種形式,可以實現各種資料介面的呼叫的統一，同時方便資料庫型別的拓展。比如要加入oracle的支援，只需要繼承idbprovider實現oracleprovider，新的postmanage繼承idataprovider重寫部分方法即可。
而業務層（posts）的呼叫通過idataprovider介面來進行統一，避免了和資料庫型別的耦合，可以在不改變業務層，表現層的**基礎上實現資料庫之間的遷移。這正是大型專案所需要的，以介面來實現層與層之間的通訊，將更多的可變因素，擴充點實現配置化。
其他子模組的介紹
1.配置
對配置的管理，小型專案可以直接使用web.config，中大型專案一般使用自己的配置解決方案。原因是：
1. 中大型專案配置檔案過多，直接使用web.config來會造成其體積過大
2. web.config直接使用字串進行讀取不方便，
試著比較一下：
siteinfo.name
3. 每次都需要進行型別轉換
discuz實現了自己的配置類，其類結構如下(以email為例)
iconfiginfo為空介面，沒有定義任何方法，主要是方便defaultconfigfilemanager傳遞，方便以後擴充。對配置檔案的解析也沒有使用.net自帶的介面，而是重新定義了介面，同時使用了xml反序列化實現配置檔案的載入和型別轉換。
**見: defaultconfigfilemanager.deserializeinfo
比較疑惑的是這個專案中某些類給出了實現，卻沒有發現呼叫。可能是相容或者擴充問題留下的，誰對這方面了解的，也可以跟帖說下。
這些類有：configprovider，iconfigfilemanager
2.資料庫表的設計
資料庫設計中有兩個引人注意的地方：
1.主題表分離
如果由我們來設計主題表和回帖表，通常的做法是如下。
這樣在獲取主題列表時，直接使用分頁演算法提取topics；檢視某一帖子時，還需要對topics，posts進行jion鏈結。
此種設計的缺陷為：
1.topics表儲存content的內容，其體積將會很大，對大體積表進行分頁，效能很慢。
2.顯示posts內容時將進行join操作，損耗效能
而discuz的做法是進行如下設計。
將topics裡的content拆分到posts中去，同時topics的主題帖也作為回帖放置到posts裡面，這樣就解決了上面我們提出的兩個問題。這是典型的違反資料庫設計正規化以換取更好效能的示例。
2．對posts表進行水平拆分
原來以為每一百萬帖子，discuz會自動進行拆分，後來發現在discuz後台能夠進行設定，手動進行分表，discuz建議每30-50萬帖子進行一次拆分。
進行拆分後，每個表的體積將會減少，保證了查詢的效率
discuz的整體架構還有很多其他值得細說的地方，例如外掛程式、擴充套件等，這些需要感興趣的人自己一一去研究，在此就不多講了.
Discuz NT 系統架構的討論
一 分析 discuz nt 支援2種資料來源，sqlserver和msaccess，但其資料庫訪問層實際上已經支援了 mysql，只是安裝程式還未提供基於 mysql 的。discuz nt採用了 頁面類 業務類 資料庫訪問類 dbhelper 資料庫 這樣的分層方式。資料庫訪問類有1個大介面3個...
親密接觸Discuz！NT之架構篇
慮到使用者的實際應用需求和面向未來的軟體開發理念，discuz nt在設計和開發之初就構建了優良的架構，大大提高了軟體的伸縮性 可擴充套件性和重用性。本架構除了使discuz nt自身結構更為清晰和更易於維護以外，也為使用者進行二次開發和完善論壇個性化提供了極大的方便。discuz nt採用了如下的...
分析Linux ALSA系統架構
alsa是 linux 音效卡驅動的架構，下面基於linux 2.6.32描述下alsa系統架構。alsa系統可以分為alsa lib alsa driver，而alsa driver又分為core層和底層硬體層。作為開發者，我們只需移植底層硬體層，根據自己硬體特性，實現底層的移植。而core層基本...