“蝉鸣林愈静，鸟鸣山更幽”，这是中国古代纯山水诗的绝句，在动与静的映衬下别具一番优美。在软件的领域，其实也存在这种动与静的境界。如果软件设计得当，也可以使软件的设计具有雕塑一般的美。对于雕塑我不是很懂，对于这种凝固的美，我一直都是十分敬畏的。
时下非常红火的是敏捷软件开发，讨论得最热闹的是设计模式。敏捷软件开发的一个价值观就是欢迎变化，拥抱变化，我可以字之为“动”。然而解决问题或者业务的变化一直是软件工程或者软件设计技术里一个最为悠久也最为棘手的问题，从来也没有一种方法可以彻底的解决。设计模式则是经验的抽象，是一种凝固，我可以子之为“静”。但是设计模式又更是以一种静止的方法处理动态的事务，或者说是使事务的处理更加动态，真是静中有动，动中有静阿。
今天我要谈的与两者似乎都没有关系。我想就我在一个项目中对系统配置或者系统参数的管理来强调和表述我的观点。
在应用领域，特别是数据库领域，我们经常需要配置一些定义信息。如在我的一个工作流管理项目中，涉及到工作流的可视化定义。工作流的可视化定义包含了很多的内容，如节点定义，进程定义，规则定义，事件定义，人员定义，权限定义等等，可以说是一个比较复杂的处理。按照通常的做法，我们将这些定义信息存储到数据表中。下次需要使用的时候再从数据库中提取出来。
上图是工作流中的一部分用例。
在使用这些定义信息的时候，我们通常的做法是如下图所示：
这样做的好处是：
只有一个好处：调用简单！！
但是由此带来的坏处是显而易见的，至少有以下几个坏处：
1。需要不停的查询数据库，每次使用的时候都要查询数据库。
2. 增加了数据库的压力。
3. 增加了网络数据的流量，同时有很多的roundtrip。效率十分低下。
4. 增加了出错的机会。
既然这样一种不好的方式，那么为什么我们还要用呢？而且又使用得这么频繁呢？也许真的是傻有傻的可爱？
然而在.Net世界里，使用.Net的几大法宝，我们就可以颠覆我们这种传统的使用方式。这几大法宝是什么呢？
A。CodeDOM
B。Reflection
C。OO
是的，就是靠这几个就可以了。
且看我们新的方式是什么：
大家注意到箭头所指的地方，原来我们是从数据库中提取信息，这次变成了从一个程序集中提取数据。
这样做的好处是
1.除非定义信息发生变化，永远不需要访问数据库
2.减少了数据库服务器的压力
3.使软件更加健壮
4.减少了网络传输的压力。
那么具体的做法是什么呢？
1.定义一个模板文件，这个文件是C#代码，类似于CodeSmith的方式。
2.在模板文件中定义一些抽象的基类
3.定义需要引用的程序集
4.将业务规则定义数据全部变成为一群业务类
5.采用CodeDom来动态编译这些文件生成一个具体的程序集
6.定义访问这些程序集的策略。如Template1101.dll，后缀1101表示模板的ID号，如果使用1101的模板，那么就直接访问Template1101.dll这个程序集。
这样我们就将需要经常访问的数据凝固起来，我称之为雕塑。
在软件系统中，如果不是经常变化的数据，我们都可以采用这样的方法来处理。个人认为这样的处理是比较优雅的。