我們打開門戶網站時，往往會看到很多排列緊密的頻道列表，如“新聞”、“財經”、“娛樂”等。頻道為網站提供了方便的導航功能。
知識准備
本文中提到的各架構方案均基於MVC(Model-View-Controller)模式，對該模式中各組成部件作如下簡短描述：
◆Model：包含業務邏輯操作以及數據訪問操作
◆View：包含UI處理相關操作
◆Controller：控制並協調View與Model的處理過程
各方案比較
方案 架構描述 代碼重用性 開發方式 部署方式 方案一 為整個網站建立一個Web Project。每個頻道對應於Web Project中的一個目錄，有點類似於ASP的處理方式。Model部件既可以包含於Web Project中，也可以封裝成Class Library。 將Model部件封裝成Class Library後將獲得較高的重用性。 模塊較為集中，開發較為快捷，但不適合大規模協作開發。 模塊較為集中，部署比較方便，但一個小的BUG可能會導致整個網站的癱瘓。 方案二 為每個頻道建立一個Web Project。每個頻道的Model部件既可以包含於相應的Web Project中，也可以分別封裝成Class Library。 每個Model部件都應用於特定的頻道，代碼分散，重用性較低。 各模塊較獨立，適合按照功能模塊分配任務的開發方式。 各模塊獨立，部署工作非常繁復，但由於各頻道是松耦合的(甚至可以位於不同的服務器)，一個頻道的故障不會影響到其他頻道的正常運行。 方案三 為每個頻道建立一個Web Project。所有頻道的Model部件封裝成一個共用的Class Library。 所有頻道共用一個Model部件，代碼較為集中，具有很高的重用性。 開發方式較為靈活，既可以按照功能模塊分配任務，也可以按照MVC各組成部件分配任務。 各模塊獨立，部署工作比較繁復，但由於各頻道是松耦合的(甚至可以位於不同的服務器)，一個頻道的故障不會影響到其他頻道的正常運行。
總結
根據上文分析，我們大致可以得出以下結論：
方案一：開發快捷，部署方便，適用於業務功能比較簡單的小型網站；
方案二：缺陷比較多，不推薦；
方案三：各模塊松耦合，代碼重用性好，適合大規模協作開發，適用於業務功能比較復雜的大中型網站。
關於Model部件
Model部件封裝了所有的業務邏輯操作以及數據訪問操作，其中可能包含對象實體類、對象操作類、數據訪問類等等。另外，筆者強烈建議對於中小型應用系統可將對象實體類、對象操作類、數據訪問類合並為一個業務邏輯類，這樣可以極大的提高開發及維護效率。
