ADO.NET中的Provider for SQL Server和Provider for Oracle将应用与厂商耦合起来，为什么要这样做?
象JDBC技术可以屏蔽后台数据库的实现厂商(限于SQL没有使用厂商特定的语法)，而ADO.NET中的for   SQL   Server和for   Oracle将应用与厂商耦合起来，为什么要这样做？

------解决方案--------------------
1.
而ADO.NET中的for SQL Server和for Oracle将应用与厂商耦合起来
============
有耦合？

哪些地方体现了耦合？

我不知道 LZ 为什么会这样理解？

2.
ADO.NET 如果同 JDBC 一样也是定义一组 .net 与数据库 API 交互的接口，具体的实现是可以由各自数据库厂商实现，也可以由第三方实现
实现这些接口的数据访问组件，.net 里面叫 Provider

3.
Microsoft .NET Data Provider for MS Sql Serrver 是
MS 为自己的 SQL 7+ 实现的，

而
.NET Data Provider for Oracle 是
MS 为 Oracle 实现的，包含在 .net fx 中，主要是考虑 oracle 的市场占有率，MS 想即使你不选择 SQL，也希望更多的 .net 应用可以方便开发基于 oracle 的系统

4。
Oracle 本身实现了一个 Provider.net

Oracle Data Provider .net 据说比 .NET Data Provider for Oracle 性能更佳

5。
难道 LZ 在 java 中连接 SQL Serrver 不要一个叫
Microsoft JDBC for SQL Server 的东东迈？就相当于 .net 的 Provider

6。
如果你说，他们都由各自的数据据访问组件，如

SqlConnection OracleConnection OleDbConnection
SqlCOmmand OracleCOmmand OleDbCOmmand

那么，是的，这是各自 Provider 的具体实现，
如果考虑多数据库的支持，你应该面向接口接口编程，
因为，他们都实现的是同一套接口

DbConnection con = CreateSqlConnection();
// 通过工厂模式实现
//DbConnection con = CreateOracleConnection();
con.Open()
// ....


------解决方案--------------------
看看这篇文章就不会有这个问题了。
http://www.cnblogs.com/Yahong111/archive/2007/07/18/822946.html

------解决方案--------------------
觉得在Membership,Role,Personalization等方面Provider Model很有优势，设计的确实有道理。

至于像楼主说的和具体数据库打交道时就显得有点，也许我还没理解透吧。设计初衷也许是数据库无关，但实际上貌似很不实际。


------解决方案--------------------
我相信微软的初衷是好的，只是微软人也并非都是元始天尊级别的！确实ADO.NET存在楼主所理解的意思，比如哪怕这样的代码：

IDbConnection conn = ...
IDbCommand cmd = conn.CreateCommand();
IDbDataParameter p = cmd.CreateParameter();
p.ParameterName = "@Name ";
cmd.CommandText = "SELECT * FROM T WHERE NAME=@Name ";
cmd.Parameters.Add(p);

你就没有办法移植，即使这个语句是标准的，因为在其他数据库上，参数名称的处理可能不是“@Name”，而是直接一个“?”。

当然，楼上的兄弟们也说明了另外一个问题，微软考虑了效率！因为特定的提供程序要比通用的ODBC或者OLEDB的效率要高一些。只是微软在通用性和效率方面没有做到最好！