在本人的“.NET简谈插件系统开发模式”一文中我们详细介绍了插件系统开发模式的优越性，尽管.NET平台或者第三方提供的平台都为我们实现了底层插件原理模型，我们可以在上面进行开发，作为一名有求知欲的程序员才是一名合格的程序员；我们不能满足系统为我们提供的功能，我们要向下沉，沉的越深越好，躲开那些应用变化给我们带来的劳累感，所以我们是否需要掌握一些别人不会的技术，才能让我们在众多的程序员中脱颖而出呢；[王清培版权所有，转载请给出署名]
我们今天来探讨“构件”系统开发模式，其实各种各样五花八名的设计模式开发模式追求的目标都是一样的，让我们开发出来的软件系统能满足日新月异的变化，这样的变化可能来自应用需求、系统支撑需求、安全需求等等，只有具备以不变应万变的机制，我们的软件才能在这样的环境中长期生存下去，软件工程的诞生为我们带来了工程化的开发管理方式，其实我们的软件系统不比那些高楼大厦开发简单，相比之下要复杂的多，亚历山大的“建筑的永恒之道”就想让我们的建筑在时间的流逝中变得更完美，更古典更适合当前的环境；我们的软件也是一样，尽量做到以不变应万变的境界，但是这样的境界可能是我们很难达到的，不可能一劳永逸；技术的发展太快了，人的精力有限，没办法学会所有的东西，只能努力去做；
构件系统模型的思想在很多书籍中都提到过，让我们的软件系统能通过不断组装来实现更新换代，将系统的实现分解成不同的“构件”，本人正在用这种模式在开发一个自己的系统，觉得前期的框架的非常耗时，但是觉得这样的框架很稳定，在不断的维护更新下我能发挥出惊人的“机械感”，所有的零件都能拆卸、跟换、组装、运行，自我感觉很好；我们要把自己当成一名工程师，要让我们设计出来的软件就好比那些“超跑”一样能在宽敞的大道上风靡起来，代码可能都一样，就要看怎么设计了，那些跑车机械工程师们都是我们学习的对象，他们热爱自己的职业，我们也要热爱自己的职业，程序员是值得骄傲的职业，至少我这么认为；
构件系统开发模式，能在不断螺旋变化中，适应新的环境或者说是恶劣的环境，我们来看一副总体结构图：[王清培版权所有，转载请给出署名]
1：
将系统的所有功能点分解成不同的构件，构件分解的粒度就要看个人技术经验了，由于不同的系统粒度也不一样；我们通过构件头统一启动所有的构件，这些构件均可以无限向下传递实现，我们公开一组程序的详细功能接口，然后由不同的构件去实现，当实现好了之后我们通过构件装配配置文件统一加载运行，配置文件只需要维护一层构件关系，就拿我们上图讲，配置文件只需要维护构件1.1、1.2、1.3三个构件，而如果1.1构件未能实现它本身应该实现的功能则这部分的责任它自己负责，我们会用同一构件接口做入口点，进入每一个一级构件，后面的每个一级构件的内部该怎么实现就怎么实现；[王清培版权所有，转载请给出署名]
2:
这是本人系统中的简单的结构设计图，我们公布一组构件要实现的接口，然后让实现者去实现；构件系统和插件系统是有明显区别，构件系统是无限实现的，请看我项目的代码图：
3:
上图中，我将所有的构件都列出，要进行这种结构设计的朋友一定要很清楚自己的每一块的作用，不能多也不能少，多了就是*，少了就不完美导致每个构件无法串联起来；为了进行这种结构设计，我们少不了配置文件；
4:
由于大型的系统可能存在N多个构件，我们有必要用XML命名空间进行区分以免节点重名冲突；系统启动的时候我们读取配置文件进行构件加载，下面我们来看一下构件是怎么无限向下传递实现的；
5:
所有的一级构件是构件头所要负责加载运行的，而当控制权到了某一个构件内部的时候由该构件去加载它的字构件；这里有个问题大家需要特别注意，当父构件要让子构件去实现某些功能的时候，只需要公开一组接口就行了，让后通过接口名称加载子构件；
本文转自 王清培 51CTO博客，原文链接：http://blog.51cto.com/wangqingpei557/587991，如需转载请自行联系原作者