CMS组件化，简单架构示意图：

Web组件使用WebPage+WebAPI的好处：

?  组件复用（组件条件管理页面复用+获取组件数据API复用）。

?  组件是分布式的第三方应用，本身高内聚、组件之间松耦合，可以理解为独立的子系统。

?  组件使用WebAPI，提供REST风格的WebService，轻量级，对客户端的要求也更少。

?  组件可以单独开发，单独测试，高度封装，可以区分不同环境，其它组件完全可以不做任何测试。

?  组件热插拔，组件易替换，可扩展性强，不会有dll相互依赖、影响，dll管理等一系列问题去处理。

?  .net/java/php/都可以开发组件，可多元化发展。

?  组件都有自己独立的版本，组件可以独立编译，独立打包和部署，当某个组件有变化的时候，可以单独对变化的组件进行版本升级，单独对变化组件进行部署。

?  组件数据的生成会有特定的环境，组件自治，组件实现方式*发挥。

?  可以单独做测试，可以独立部署、运行、调试等。

?  可以整合不同的开发平台（.net/java/php/...）开发出来的WEB组件。

?  甚至组件可以独立出去，由第三方去开发，维护，CMS平台可以管理这些组件，热插拔这些组件。

?  性能使用分布式的组件应该更好，如果组件都集中在CMS平台去统一调用数据，压力应该会更大。万一某个组件出故障而不会影响到整个页面展现。

?  组件数据也可以通过定时策略去拉取完成，根据组件配置。

?  为了简化组件部署， CMS平台可以准备好几类组件的虚拟目录去Host组件应用，也不用每个组件都是一个虚拟目录。【使用Restful风格架构的WebAPI暴露接口，更轻量化】

Web组件使用DLL的问题：

?  dll管理麻烦，需要考虑集群、存储、依赖项dll、验证、配置、部署、问题排查维护、下线等。

?  dll限制了只能.net去开发，很难整合不同的开发平台（.net/java/php/...）开发出来的组件。

?  dll限制了组件的实现方式，有较大的约束，不能*发挥，影响生产力。

?  dll方式的组件条件页面较难管理和生成。

?  dll对多种环境配置、日志、调试等带来很多麻烦。

?  dll没有完全隔离，控制不好会影响到其他组件，而且怎么做隔离，有技术壁垒和风险。

?  dll方式对开发成本要求高，有技术风险。

?  组件有依赖的配置，依赖dll ，依赖的环境等很多变化因素，dll很难去完全覆盖及支持到。

?  组件条件管理页面可能是很多组件公用的，不好分开。

?  获取组件数据API可能是很多组件公用的，不好分开。

?  dll区分不同环境比较麻烦，对开发，测试都很难控制。

?  dll依赖部署环境，若一个组件不想使用此环境，比如现在是II7.5+.net4.0集成环境应用程序池，如果有个组件要.net4.5开发的，或者需要.net4.0经典环境应用程序池，不能兼容等不好控制问题。

?  dll组件数据的生成会有特定的环境，平台自治+组件dll支持，组件调用出问题责任不明确。

?  dll很难做测试，不能独立运行。

 

组件如何实现示意图：

 

组件数据可以使用动态类型：

 

可以使用开源的Razor模板解析引擎，参考：Razor Generator