告别ADO.NET实现应用系统无缝切换的烦恼(总结篇)
2024-07-10 12:38:26
供稿：网友
可能只是那么想也是那么设计的，要支持多数据库，要能支持多数据库，万一要是以后数据库变了怎么办？万一要是。。。怎么办？这些顾虑很多时候是不必要的，反而绕了弯子。大都是做项目应用系统而非产品，即使要用不同的数据库了，基本上是吧上一个项目全COPY过来，修修改改OK了。产品可能就不一样了，那才可能要支持真正的多数据库，才可能会面对真正的数据库访问类库的多数据库的实际检验。ADO.NET2.0下增强了数据库访问的功能，也就是工厂式类库，提到工厂式数据库访问，网上可就多了，ADO.NET2.0增强的工厂式网上也很多了，都说只要改动webconfig里的数据库连接就行了，其它什么地方都不用改了，看了几篇都是点了下，不知道做过充分测试没有，应该说在实际的多数据库产品系统中，还要做很多修正，完善和测试的。
说正题，假设（只是假设，真的不会这么变态，呵呵）一产品系统要支持ACCESS,SYBASE,SQL SERVER,ORACEL数据库，系统开发完后，要求只改动数据库的连接，也就是说只改动webconfig，来实现系统的无缝切换，其它什么也不改动，可能有的觉得简单，但是要经得起实际检验还是要花点时间测试的，当然写是不算难，见到过有的应用系统开发中，所有的DML语句都以XML形式放在config配置文件里，然后用封装好的数据库访问组件读config配置文件执行SQL语句，开发人员只要建个config文件把增删改查语句写那里就可以，当然这么来有个好处，就是做到了与数据库的无关性了，如果数据库访问组件做的完善的，当然是可以做到系统无缝切换到其它数据库的，当然同时也有缺陷，项目中不仅仅是DML语句吧，有的稍微复杂点的逻辑，存储过程要用下吧，我自己也趋向于喜欢用存储过程，自定义函数来处理稍微复杂的逻辑，而且把DML语句都放在配置文件里我也是不能忍受的，可能是一个个人的习惯吧。
继续，下面开始我要说的利用ADO.NET2.0及以上版本新增的工厂式数据库访问实现应该系统的无缝切换，要实现无缝切换，当然还是要有前提条件了，就是各个不同的数据库之间的表和其它对象都已经成功移植了，没有这个前提，纯用ADO.NET做系统无缝切换那是不可能的了，比如SQL SERVER中写的存储过程，自定义函数直接复制到ORACLE上就行了吗？当然是不行，写法及变量定义要做些调整才可以成功移植的，还有变结构字段类型等等的都可能是要做相应调整，这些都做好了才能谈系统的无缝切换。要做的无缝切换，数据库访问层的代码中最好（并非绝对）不应该出现SqlCommand，SqlDataAdapter,SqlClient,SqlXXX吧，要切换到ORACLE数据上，甲骨文会把你的SqlXXX玩死的，ORACLE里可以OracleCommand，OracleXXX，还有程序执行带参数语句时，比如 where userid=@userid，甲骨文也会玩死你的，oracle里可是where userid=:userid，@前缀在ACCESS,SYBASE,SQL SERVER里是都认得，还有还有字段名的写法问题，ORACLE里可以区分大小写的，比如可能大多习惯这样命名属性和自段,UserName,UserAge，如果在ORACLE里这么命名的话，系统开发过程中的那种痛苦也许只有经历过的人才知道，ORACLE坚持大写为标准，记得很久很久以前的一个夏天的晚上，那时我还是年轻的80后，一位数据库设计比较N的人提到过，尽量在数据库设计和T-SQL编程中采用大写标准，基本上接触的SQL SERVER数据库较多，也习惯了表名，字段名的大写设计，后来发现确实是有道理的。这里提到的问题都是在下面的各个方法中为了兼容不同的数据库需要面对的问题，具体讲到每个执行方法时再具体解释。刚才说SqlCommand,OracleComand都是各自认得，但是DbCommand可是大家都认得的，暂且叫抽象对象吧，还有DbConnection，DbDataAdapter等都是他们都认得的，所以在做支持多数据库访问类库时，就可以用这些对象了，根据这些对象再创建具体对象。ADO.NET2.0中数据库访问工厂中有个 DbProviderFactory 对象，也就是通常说的DataProvider了，正是这个起了关键和方便的作用，是用来创建提供程序对数据源类的实现的实例（就是用来创建实例）。另外数据库操作还要用到参数吧，DbParameter，DbParameterCollection下面都需要用到，先贴一段类库的构造函数，因为共用对象需要先实例化。
