.NET简谈构件系统开发模式

转自[王清培] http://www.cnblogs.com/wangiqngpei557/archive/2011/06/14/2080416.html

在本人的“.NET简谈插件系统开发模式”一文中我们详细介绍了插件系统开发模式的优越性,尽管.NET平台或者第三方提供的平台都为我们实现了底层插件原理模型,我们可以在上面进行开发,作为一名有求知欲的程序员才是一名合格的程序员;我们不能满足系统为我们提供的功能,我们要向下沉,沉的越深越好,躲开那些应用变化给我们带来的劳累感,所以我们是否需要掌握一些别人不会的技术,才能让我们在众多的程序员中脱颖而出呢;

我们今天来探讨“构件”系统开发模式,其实各种各样五花八门的设计模式开发模式追求的目标都是一样的,让我们开发出来的软件系统能满足日新月异的变化,这样的变化可能来自应用需求、系统支撑需求、安全需求等等,只有具备以不变应万变的机制,我们的软件才能在这样的环境中长期生存下去,软件工程的诞生为我们带来了工程化的开发管理方式,其实我们的软件系统不比那些高楼大厦开发简单,相比之下要复杂的多,亚历山大的“建筑的永恒之道”就想让我们的建筑在时间的流逝中变得更完美,更古典更适合当前的环境;我们的软件也是一样,尽量做到以不变应万变的境界,但是这样的境界可能是我们很难达到的,不可能一劳永逸;技术的发展太快了,人的精力有限,没办法学会所有的东西,只能努力去做;

构件系统模型的思想在很多书籍中都提到过,让我们的软件系统能通过不断组装来实现更新换代,将系统的实现分解成不同的“构件”,本人正在用这种模式在开发一个自己的系统,觉得前期的框架的非常耗时,但是觉得这样的框架很稳定,在不断的维护更新下我能发挥出惊人的“机械感”,所有的零件都能拆卸、跟换、组装、运行,自我感觉很好;我们要把自己当成一名工程师,要让我们设计出来的软件就好比那些“超跑”一样能在宽敞的大道上风靡起来,代码可能都一样,就要看怎么设计了,那些跑车机械工程师们都是我们学习的对象,他们热爱自己的职业,我们也要热爱自己的职业,程序员是值得骄傲的职业,至少我这么认为;

构件系统开发模式,能在不断螺旋变化中,适应新的环境或者说是恶劣的环境,我们来看一副总体结构图:

.NET简谈构件系统开发模式
将系统的所有功能点分解成不同的构件,构件分解的粒度就要看个人技术经验了,由于不同的系统粒度也不一样;我们通过构件头统一启动所有的构件,这些构件均可以无限向下传递实现,我们公开一组程序的详细功能接口,然后由不同的构件去实现,当实现好了之后我们通过构件装配配置文件统一加载运行,配置文件只需要维护一层构件关系,就拿我们上图讲,配置文件只需要维护构件1.1、1.2、1.3三个构件,而如果1.1构件未能实现它本身应该实现的功能则这部分的责任它自己负责,我们会用同一构件接口做入口点,进入每一个一级构件,后面的每个一级构件的内部该怎么实现就怎么实现;

.NET简谈构件系统开发模式
这是本人系统中的简单的结构设计图,我们公布一组构件要实现的接口,然后让实现者去实现;构件系统和插件系统是有明显区别,构件系统是无限实现的,请看我项目的代码图:

.NET简谈构件系统开发模式
上图中,我将所有的构件都列出,要进行这种结构设计的朋友一定要很清楚自己的每一块的作用,不能多也不能少,多了就是*,少了就不完美导致每个构件无法串联起来;为了进行这种结构设计,我们少不了配置文件;

.NET简谈构件系统开发模式
由于大型的系统可能存在N多个构件,我们有必要用XML命名空间进行区分以免节点重名冲突;系统启动的时候我们读取配置文件进行构件加载,下面我们来看一下构件是怎么无限向下传递实现的;

.NET简谈构件系统开发模式
所有的一级构件是构件头所要负责加载运行的,而当控制权到了某一个构件内部的时候由该构件去加载它的字构件;这里有个问题大家需要特别注意,当父构件要让子构件去实现某些功能的时候,只需要公开一组接口就行了,让后通过接口名称加载子构件;

[王清培版权所有,转载请给出署名]

上一篇:矩阵经典题目六:poj 3070 Fibonacci


下一篇:hdu 2586 How far away ?(LCA - Tarjan算法 离线 模板题)