6.1w+
社区成员
关于ADO.NET设计模型上的困惑？
我刚刚接触ADO.NET，对这个新的数据访问模型的设计思路有一些疑惑，希望已经体会到其中真味的朋友给点指点。
ADO.NET为什么没有像ADO一样提供一组"接口模型"，而是直接把类暴露给开发者。这样一来，我们写的程序不得不针对不同数据库"硬编码"，就像：
OracleConnection conn;
OracleCommand cmd;
...
SqlConnection conn;
SqlCommand cmd;
然而以上代码，除了类名不同以外，语句基本上没什么区别，类似如下：
conn.open();
reader = cmd.executeReader(...)
...
conn.Close();
虽然只有类名不同，但是为了支持不同的数据库，代码也要被迫写多遍。而原来的ADO则不强迫你硬编码数据库的类型，只是在ConnnectionString的provider中设的OLEDB的driver不同。ADO.NET为什么不再多加入一个类似JDBC中的DriverManager类，输入不同的Provider字符串返回具体connection类的接口呢。.NET具有那么强大的Assembly动态分析加载功能，做这个不是小菜一碟吗？
当然，针对不同数据库，Data Access Layer的类实现起来肯定会不一样的，尽量发挥而不是抹煞各个数据库的特色，是Data Access Layer的职责。那么针对Oracle的实现里用OracleConntion...，针对SqlServer的实现用SqlConntion如此这般就成了顺理成章的事，即使在接口模型上统一了代码，到具体实现还是要分开(比如SQL语句不同，表的设计不同），那上面说的接口模型好像意义也不大了，PetShop3和Duwamish就是这么设计的DAL。可是这里有一个问题，就是选择设计模型的自由没有了，你被强迫使用区别对待的模型(ADO.NET)，而不能用风格统一的接口模型（像ADO，JDBC的模型），而后者的自由在于你即可以用统一风格也可以区别对待。比如，SQL Server的日期字段是这样操作：
... WHERE create_date='2003-07-08'
Oracle的是这样
... WHERE create_date=to_date('2003-07-08','yyyy-mm-dd')
假如对这个字段的操作只有写入和取出打印，那我就想模糊这种区别，统一用varchar。
在ADO.NET中你就没的选择，只有写两遍:
OracleConnection conn...
SqlConnection conn...
而在ADO或JDBC中你只需写一遍:
Connection conn
以前用MFC,ATL以及其它的MS的framework时，总感觉不是特别舒服，觉得微软的东西挺实用，但在设计上总是差了那么一点。现在推出的.NET是微软精心打造的，说是为了未来十年设计的.ADO.NET又是重新设计的，可是，不会在现在开发中就这么不顺手吧。
盼望高人指点
ADO.NET为什么没有像ADO一样提供一组"接口模型"，而是直接把类暴露给开发者。这样一来，我们写的程序不得不针对不同数据库"硬编码"，就像：
OracleConnection conn;
OracleCommand cmd;
...
SqlConnection conn;
SqlCommand cmd;
然而以上代码，除了类名不同以外，语句基本上没什么区别，类似如下：
conn.open();
reader = cmd.executeReader(...)
...
conn.Close();
虽然只有类名不同，但是为了支持不同的数据库，代码也要被迫写多遍。而原来的ADO则不强迫你硬编码数据库的类型，只是在ConnnectionString的provider中设的OLEDB的driver不同。ADO.NET为什么不再多加入一个类似JDBC中的DriverManager类，输入不同的Provider字符串返回具体connection类的接口呢。.NET具有那么强大的Assembly动态分析加载功能，做这个不是小菜一碟吗？
当然，针对不同数据库，Data Access Layer的类实现起来肯定会不一样的，尽量发挥而不是抹煞各个数据库的特色，是Data Access Layer的职责。那么针对Oracle的实现里用OracleConntion...，针对SqlServer的实现用SqlConntion如此这般就成了顺理成章的事，即使在接口模型上统一了代码，到具体实现还是要分开(比如SQL语句不同，表的设计不同），那上面说的接口模型好像意义也不大了，PetShop3和Duwamish就是这么设计的DAL。可是这里有一个问题，就是选择设计模型的自由没有了，你被强迫使用区别对待的模型(ADO.NET)，而不能用风格统一的接口模型（像ADO，JDBC的模型），而后者的自由在于你即可以用统一风格也可以区别对待。比如，SQL Server的日期字段是这样操作：
... WHERE create_date='2003-07-08'
Oracle的是这样
... WHERE create_date=to_date('2003-07-08','yyyy-mm-dd')
假如对这个字段的操作只有写入和取出打印，那我就想模糊这种区别，统一用varchar。
在ADO.NET中你就没的选择，只有写两遍:
OracleConnection conn...
SqlConnection conn...
而在ADO或JDBC中你只需写一遍:
Connection conn
以前用MFC,ATL以及其它的MS的framework时，总感觉不是特别舒服，觉得微软的东西挺实用，但在设计上总是差了那么一点。现在推出的.NET是微软精心打造的，说是为了未来十年设计的.ADO.NET又是重新设计的，可是，不会在现在开发中就这么不顺手吧。
盼望高人指点
...全文
当前发帖距今超过3年，不再开放新的回复
发表回复
panyee 2003-07-19
- 打赏
- 举报
你从VC转过来的吗？
每个数据库连接都有一定的优化，不能说就是不好吧
每个数据库连接都有一定的优化，不能说就是不好吧
justleon 2003-07-19
- 打赏
- 举报
我明白了，刚才仔细看了MSDN.其实每个数据访问组件都实现了接口模型，怪自己不细心，随便抄了几个书上的例子就乱下断言。不过也证明我想的没错:)
OleDBConnection、SqlConnection实现IDbConnection接口
OleDbCommand、SqlConnection实现IDbCommand接口
...以此类推
OleDBConnection、SqlConnection实现IDbConnection接口
OleDbCommand、SqlConnection实现IDbCommand接口
...以此类推
justleon 2003-07-19
- 打赏
- 举报
to panyee(快乐王子):
采用接口模型并不妨碍实现类的优化啊。我想你说的优化可能是扩展性吧。其实在接口模型也可以实现的。假设在Command接口上我想调用一个针对oracle的FastExecuteOnOracle(BSTR SQL),可以让Command接口加入一个特化的方法叫QueryExtendInterface(IUnkown **ppv);返回一个针对Oracle的增强接口，这个接口里定义了FastExecuteOnOracle(...)。QueryExtendInterface也可以返回针对SQL SERVER的增强接口等，就看你用的provider是什么了。
to Corny():
我想OLEDB和ODBC是为了向下兼容而设的，各种命名空间的使用顺序是：专用命名空间->OLEDB->ODBC，我的困惑在专用命名空间这一块，在OLEDB中的确没有这些问题。
采用接口模型并不妨碍实现类的优化啊。我想你说的优化可能是扩展性吧。其实在接口模型也可以实现的。假设在Command接口上我想调用一个针对oracle的FastExecuteOnOracle(BSTR SQL),可以让Command接口加入一个特化的方法叫QueryExtendInterface(IUnkown **ppv);返回一个针对Oracle的增强接口，这个接口里定义了FastExecuteOnOracle(...)。QueryExtendInterface也可以返回针对SQL SERVER的增强接口等，就看你用的provider是什么了。
to Corny():
我想OLEDB和ODBC是为了向下兼容而设的，各种命名空间的使用顺序是：专用命名空间->OLEDB->ODBC，我的困惑在专用命名空间这一块，在OLEDB中的确没有这些问题。
Corny 2003-07-19
- 打赏
- 举报
我想楼主没弄清楚 ado.net
事实上ado.net也提供类似于ado的OLEDB联接,也就是用不同的OLEDB Provider的联接方式,只是在此之外,它提供了更多的优化类型的接口,就象原来使用的dao针对access 优化一样,现在则提供了如SQLClient对ms sql进行优化等,事实上这些类都可以用OLEDB去代替的
不信的话你可以用OLEDB联接SQL数据库试试,甚至你可以全部使用ODBC Provider去联接所有的数据库,是没有问题的,主要是效率问题.
事实上ado.net也提供类似于ado的OLEDB联接,也就是用不同的OLEDB Provider的联接方式,只是在此之外,它提供了更多的优化类型的接口,就象原来使用的dao针对access 优化一样,现在则提供了如SQLClient对ms sql进行优化等,事实上这些类都可以用OLEDB去代替的
不信的话你可以用OLEDB联接SQL数据库试试,甚至你可以全部使用ODBC Provider去联接所有的数据库,是没有问题的,主要是效率问题.
xhuayu 2003-07-19
- 打赏
- 举报
不清楚，现在还没有入门。高手多指点。