本文主要討論在ASP.Net框架下實現多頻道網站架構的幾種方案，並從代碼重用性、開發方式、部署等幾個方面來對各方案進行分析。
表現層 整個網站的表現層（。aspx，。ascx，。css，。JS等文件及其對應的。cs文件）都位於一個Web Project中，每個頻道對應於一個目錄，每個頻道下面可能有"Images"、"Style"等子目錄。這是最簡單的一種方式，類似於ASP中的處理方式。 各頻道的表現層（。aspx，。ascx，。CSS，。JS等文件及其對應的。cs文件）分別位於不同的Web Project中。各頻道的表現層（。ASPx，。ascx，。CSS，。JS等文件及其對應的。cs文件）分別位於不同的Web Project中。
業務層 可與表現層位於同一個項目或者包含在獨立的Class Library Project中。
可與各頻道表現層位於同一個項目或者分別包含在獨立的Class Library Project中。 包含在獨立的Class Library Project中，供所有頻道表現層調用。
代碼重用性 建議將業務層包含在獨立的Class Library Project中，這樣能獲得較高的重用性。 每個頻道都有與其對應的業務層，代碼較為分散，重用性較低。 所有頻道共用一個業務層，代碼較為集中，具有很高的重用性。
開發方式 模塊較為集中，開發較為快捷，但不適合多人協同開發。 各模塊較獨立，適合按照模塊分配任務的開發方式。 開發方式較為靈活，既可以按照模塊分配任務，也可以按照架構的各組成層分配任務
部署 模塊較為集中，部署比較方便，但一個小的BUG可能會導致整個網站的癱瘓。模塊比較分散，部署非常困難，但由於各頻道是松耦合的，一個頻道的故障不會影響到其他頻道的正常運行。模塊比較分散，部署比較困難，但由於各頻道是松耦合的，一個頻道的故障不會影響到其他頻道的正常運行。
關於業務層：
這裡的業務層比較抽象，可以拆分為對象實體層、對象操作層、數據訪問層等。筆記強烈建議對於中小型系統可將對象實體層、對象操作層、數據訪問層合並為一個業務邏輯層，這樣可以極大的減少開發及維護成本。
