工厂模式的思考和实现 技术讨论
对工厂模式有一点理解，为了方便系统的维护和升级以及数据库的更换所有工厂模式产生了

  比如说你做了一个sql版的系统[三层框架]
  客户突然想要一个Oracle版的系统【三层框架】
  这两个系统除了dal层不同，其他地方都一样
  所有工厂模式就起到了作用
  首先定义了dal层的标准【有哪些方法】
  然后呢根据配置文件生产具体的工厂【就是决定使用哪种数据库】
  当然两个乃至多个数据访问层都要根据dal层标准【即实现接口】来进行编写
  然后就回到了原来的三层
   


  我做了一个项目，使用了工厂模式【sql 和Oracle 】，但是现在想尝试将DBHelper 文件工厂化 就是根据配置文件动态的决定我要获得的
connection对象是salconnection 或是Oracleconnection对象  

这样我在原来三层的基础上使用用工厂决定我的DBHelper 后就可以实现 一个dal层 同时使用两个数据库类型
就是Oracle 或者sql  
 缺点：各个数据库类型中存在差异...dal层【调用存储过程】很难统一 违背的工厂模式的本质
我只是想尝试一下
 现在我遇到了一下困难，正如我刚才所说 ：各个数据库类型中存在差异...dal层很难统一 所以Oracle的查询存储过程和sql的有区别，我不知道在这里如何统一...其他的增删改没有什么大的区别，可以统一

希望大家讨论一下，帮忙实现以 统一在DAL层sql和Oracle的查询方法...

------解决方案--------------------
在写一个OrcalHelper类
------解决方案--------------------

探讨

在写一个OrcalHelper类

------解决方案--------------------
好！我支持一下！回去考虑考虑！……
------解决方案--------------------
将字符sql 替换成oracle就行了
------解决方案--------------------
哦，呵呵Sorry，我又看了一下你的代码，你就是DBConnection写的。

我是用了几秒钟看了一下DalFactory.DBfactory这个词，想当然地以为你煞有介事地写一堆什么DAL层代码去了。

其实只需要DalFactory.DBfactory.Createconnect一个方法，你完全没有必要搞这么宏伟的命名。由于System.Data.Common本来就是DAL架构，因此完全不用像搞java的那些人喜欢的那样自己搞一堆代码出来。

看上去你只要两个两个小方法，一个创建DBConnection实例，另一个则根据命令名字从资源文件或者xml/文本文件中找出对应的命令。只要这两个小方法，一个仅限于ADO.NET层次的DAL层核心架构开发就完成了。



不过要知道，这只限于ADO.NET层次。
------解决方案--------------------
继承接口写oracle操作类
在WEB.CONIG中配置相关参数
(IDBUtility)Assembly.GetExecutingAssembly().CreateInstance(typeName);
------解决方案--------------------
两个helper，
DAL就用DbType，DbDataReader，DbCommand Db…………
不知道是不是这样就行了。
------解决方案--------------------
见贤思齐焉
------解决方案--------------------
根本就看不懂 sp1234的代码
我只知道他用到了太多的新技术

------解决方案--------------------
sp1234一般只说理论，代码很少的，就是有代码，一般也是一般人看不懂的。
期待他能改变下风格，用最简单的代码例子诠释高深的理论，
哈哈，别不舒服哦sp1234
------解决方案--------------------
顶
哈