当我编写应用程序时，我使用System.Data接口（IDbConnection，IDbCommand，IDataReader，IDbDataParameter等...）。我这样做是为了减少供应商的依赖性。除非，我正在做一个简单的测试应用程序，在咨询时这似乎是道德的事情。
但是，我看到的所有代码似乎都使用System.Data.SqlClient命名空间类或其他特定于供应商的类。在杂志和书籍中，很容易将其归结为微软的影响力以及他们的营销转向仅针对SQLServer进行编程。但它看起来像我看到的几乎所有.NET代码都使用SQLServer特定的类。
我意识到供应商特定的类具有更多功能，例如向SqlCommand对象添加参数是一种方法，其中将其添加到IDbCommand是令人恼火的4+行代码。但话又说回来;为这些限制编写一个小助手类非常简单。
我还想知道当SQLServer是当前目标客户端时是否对接口进行编程是否过度工程，因为它不是立即需要的。但我不认为这是因为针对接口编程的成本太低，因为减少供应商依赖性会带来如此巨大的好处。
您是否使用供应商特定的数据类或接口？
编辑：总结下面的一些答案，并在阅读时提出一些想法。
使用接口实现供应商中立的可能陷阱：
使用接口的正面理由：
答案 0 :(得分：4)
要考虑的一件事是您切换数据库的实际机会。在大多数情况下，这绝不会发生。即使它确实如此，即使您使用数据库中立的类，它也将是一个重大的重写。在这种情况下，最好使用功能更丰富的功能，并帮助您更快地完成项目。
话虽如此，我认为在大多数情况下，您应该使用自己创建的图层，在实际的.Net API之上，这样如果您必须更改必须使用的类，那么它将不会这么多问题。即使您停留在同一个数据库中，也永远不知道何时需要切换访问数据库的方式。从ASP迁移到ASP.Net（ADODB与ADO.Net）的任何人都可以告诉你这是多么痛苦。
所以我认为最好的解决方案是使用功能更丰富的特定于数据库的API，并在其上构建自己的层，以便在必要时可以轻松地将其交换出来。
答案 1 :(得分：3)
根据您正在与之交谈的数据库引擎的类型，您必须为这些类提供不同的SQL，因此即使您设法编写所有代码以使用接口，您仍然需要编写多组SQL。
或者，你可以做我们已经完成的工作，编写我们自己的图层来处理我们使用的所有语法，这不是不同引擎提供的所有语法，但足以管理编写一个获得的SQL在执行之前正确地重写。
基本上我们已经创建了一个函数语法，其中我们使用SQL::为函数的名称添加前缀，这使我们的代码能够识别需要重写的特殊函数。然后将这些解析出来并正确地重写，甚至可以在必要时交换参数顺序。
可以完成返回当前服务器日期和时间的函数名称之类的小事，但也可以做更大的事情，比如如何选择查询的前N行。
此外，SQL Server的参数写为@name，其中OleDb使用位置（只需在参数中添加？），我们的代码也会处理这些差异。
在我们不需要担心需要编写的SQL的意义上，它会得到回报。
答案 2 :(得分：2)
我写的是类似于lassevk所说的东西，但他打败了我。
此外，您必须在某个时候与真实数据库交谈。您可以通过界面代码将大部分数据访问包装起来，这是一个好主意。但最终如果您使用的是SQL Server，则需要创建SqlClient.SqlConnection的实际实例。对于Access，Oracle或MySQL也是如此。
答案 3 :(得分：1)
我使用特定于供应商的类，我正在进行直接数据库工作（除非我被告知可能最终使用不同的数据库 - 已发生的次数：一次）。
但是，如果我最终将一些非db特定代码分解为单独的类，我将经常制作方法参数接口 - 特别是如果我认为它在其他项目中有用，并且我不依赖于任何直接访问类的具体功能。
基本上，用爱因斯坦的话来说：让解决方案尽可能简单，但并不简单。
答案 4 :(得分：1)
您应该尝试编写与代码数据库无关的代码。也许你现在没有发现它有用，但你将来可能会利用它。
答案 5 :(得分：0)
查看Microsoft的模式和实践组的企业库。 他们在那里的数据访问代码显示了一些提供者独立性的良好实现。