IdbConnection对SqlConnection

Question

在编写应用程序时，我使用System.Data接口(IDbConnection、IDbCommand、IDataReader、IDbDataParameter等)。我这样做是为了减少供应商的依赖。除非，我正在做一个简单的测试应用程序，这似乎只是做道德的事情时，咨询。

但是，我看到的所有代码似乎都使用System.Data.SqlClient命名空间类或其他特定于供应商的类。在杂志和书籍中，很容易将其归因于微软的影响力和他们的营销策略，只针对SQLServer。但是，它与我看到的几乎所有.NET代码一样，都使用SQLServer特定的类。

我意识到，特定于供应商的类具有更多的功能，例如，向SqlCommand对象添加参数是一种方法，当将它添加到IDbCommand中时，会有令人讨厌的4+代码行。但是，同样地，为这些限制编写一个小助手类非常简单。

我还想知道，当SQLServer是当前目标客户端时，针对接口的编程是否过于工程化，因为它不是立即需要的。但我不认为这是因为针对接口进行编程的成本如此之低，因为降低对供应商的依赖提供了如此巨大的好处。

您是否使用特定于供应商的数据类或接口？

编辑:总结一下下面的一些答案，并在阅读时加入一些我的想法。

使用接口实现供应商中立可能存在的缺陷：

• Vendor特定的关键字嵌入在SELECT语句中(所有ins、upd和del都在procs中，所以这不是问题)直接绑定数据库的
• 可能会导致问题。
• ，除非您的连接实例化是集中的，否则无论如何都需要调用特定于供应商的类。

使用接口的积极理由：

根据我的经验，在可重用代码库customer.

• Use

中，迁移到不同供应商的能力(即使没有使用)一直受到接口的赞赏。

Answer 1

根据与您交谈的数据库引擎的类型，您必须给出类的SQL有不同之处，所以即使您设法编写了所有代码来使用这些接口，仍然需要编写多组SQL。

或者，您可以做我们已经做过的事情，编写我们自己的层，负责我们使用的所有语法，这并不是由不同引擎提供的所有语法，而是足够在执行之前编写一个被正确重写的SQL。

基本上，我们已经创建了一个函数语法，在函数的名称前加上SQL::，这样我们的代码就可以识别需要重写的特殊函数。然后，对这些参数进行解析，并适当地重写，甚至在必要时还可以交换参数顺序。

可以做一些小事情，比如返回当前服务器日期和时间的函数的名称，但也可以做更大的事情，比如如何选择查询的前N行。

此外，Server的参数编写为@name，其中OleDb使用位置(只需添加一个？)我们的代码也处理这些差异。

它带来了回报，因为我们不太担心需要编写的SQL。

Answer 2

需要考虑的一件事是，您将切换数据库的实际机会。在大多数情况下，这种情况永远不会发生。即使是这样，它也将是一个主要的重写，即使您使用的类是数据库中立的。在这种情况下，最好使用更丰富的特性，并帮助您更快地完成项目。

尽管如此，我认为在大多数情况下，您应该使用一个您自己创建的层，而不是实际的.Net API，这样如果您必须更改您必须使用的类，那么就不会有太多问题了。即使您停留在同一个数据库上，您也永远不知道什么时候必须切换访问数据库的方式。任何从ASP迁移到ASP.Net (ADODB与ADO.Net)的人都可以告诉您这有多痛苦。

因此，我认为最好的解决方案是使用功能更丰富的特定于数据库的API，并在其之上构建自己的层，以便在必要时可以轻松地将其交换出去。

Answer 3

我写的东西和拉塞夫克说的差不多，但他比我强。

此外，您还必须在某个时候与一个真正的数据库进行交谈。您可能可以使用接口代码包装大部分数据访问，这是个好主意。但是，最终，如果您使用Server，您将希望创建一个真正的SqlClient.SqlConnection实例。Access、Oracle或MySQL也是如此。