设计模式在工作中的应用（二）

系统数据层采用O/R mapping技术实现的，今天的重点不是介绍如何实现数据层，而是讲述数据层其中的一个需求。什么需求呢？就是在在最后解析的Sql语句中需要支持SqlServer的函数，比如将字符串转换为时间、截取字符串的字段，这些功能在SqlServer中有对应的函数来完成。需要说明的是Sql语句不是程序中写入的，而是通过实体按照不同的操作解析生成的。所以还不能直接增加数据库的函数。
这里我们不介绍如何进行解析生成Sql语句，怎么解析的不重要，只要知道这些都是解析类，转换为Sql语句的不同部分。我是想说说针对上面的需求，我是如何考虑的。

需要能够使用SqlServer的函数？大概想一想，感觉很容易啊，不就是封装一个函数类，实现SqlServer数据库的函数。是的，最根本的实现也就是这些。那还有什么需要考虑的呢？那就来找找什么是变化的。首先想到的肯定是不同的数据库，能支持SqlServer数据库，当然也得考虑扩展到Oracle数据库， 这样就找到一个变化点。（没办法，公司系统主要是MIS，所以动不动就要关心不同的数据库）支持不同数据库，没问题，每个函数都实现不就好了吗，没什么大不了的。打开数据库函数列表，我晕，一大堆，如果都要实现，我看这个框架也就别做了，忙着实现这些函数功能就好了。而且，现在也不知道以后的新系统会用到哪些函数。最常用的函数肯定需要实现，用的多啊。如果哪天需要用到一个新的数据库函数而又数据层又没有实现，怎么办？有办法，修改函数类，增加一个方法即可。嗯，不错，解决了问题。问题是，一个、两个可以，日子长了，不得改个没完。所以数据库不断增加的函数是第二个变化点。

暂时只找到了两个变化点，现在该如何来封装这两个变化点？我是这样来做的，针对不同数据库，采用了strategy模式，这样可以实现不同数据的函数解析。第二个变化点，为了能动态的支持数据库的函数，选择了visitor模式，这样在实现了常用函数后不用担心修改不断增加的数据库函数了。

好了，下周继续。

对了，简图如下：