承接基于.Net的系统研发,精通物流系统,特别是仓储物流管理,有意者请联系。

设计模式在工作中的应用(二)

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

这里我们不介绍如何进行解析生成Sql语句,怎么解析的不重要,只要知道这些都是解析类,转换为Sql语句的不同部分。我是想说说针对上面的需求,我是如何考虑的。

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

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

对了,简图如下:

posted @ 2007-10-12 16:20  阿修罗一平  阅读(1808)  评论(4编辑  收藏  举报