【引自Kenny的博客】背景
我们打开门户网站时，往往会看到很多排列紧密的频道列表，如“新闻”、“财经”、“娱乐”等。频道为网站提供了方便的导航功能。
知识准备
本文中提到的各架构方案均基于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部件封装了所有的业务逻辑操作以及数据访问操作，其中可能包含对象实体类、对象操作类、数据访问类等等。另外，笔者强烈建议对于中小型应用系统可将对象实体类、对象操作类、数据访问类合并为一个业务逻辑类，这样可以极大的提高开发及维护效率。
下面我们将对其中第三种方案的具体实现方法进行分解。首先我们来看下该方案的主体架构。
主体架构
各频道分别位于不同的Web Project(具有独立的二级域名)，并将所有的业务逻辑以及数据访问功能封装成Class Library，所有频道共用这个Class Library。如下图所示：
 |
| 多频道网站主体架构图 |
下面详细介绍实现方法。
假设网站有三个频道，新闻、论坛以及博客，对应的二级域名为"news"、"forum"、"blog"。除此之外，还需要另外定义两个域名，分别用于网站首页以及用户注册、登陆功能(基于Passport机制，本文后面将作详细介绍)，对应域名为"homepage"、"passport"。 |
