.net IdbConnection与SqlConnection

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

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

我意识到特定于供应商的类具有更多的功能，例如，将参数添加到SqlCommand对象是一种方法，而将其添加到IDbCommand是一种令人恼火的4行以上的代码。但话说回来；为这些限制编写一个小助手类非常简单

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

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

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

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

• 嵌入在中的特定于供应商的关键字 您的SELECT语句（所有我的ins、， upd和del都在进程中，因此 （没问题）
• 直接绑定 数据库可能会导致 问题
• 除非你的连接 实例化是集中式的 特定于供应商的类将需要 无论如何都要打电话

使用接口的积极原因：

• 根据我的经验，这种能力（甚至 如果未行使）移动到 不同的供应商一直是不同的 受到客户的赞赏
• 在可重用代码库中使用接口

---

我在做直接数据库工作时使用特定于供应商的类（除非有人告诉我，我们可能最终使用不同的数据库-发生的次数：一次）

然而，如果我最终将一些非db特定的代码分解成单独的类，我通常会使方法参数成为接口——特别是如果我认为它在其他项目中有用，并且我不依赖direct access类的任何特定功能

---

基本上，套用爱因斯坦的话：使解决方案尽可能简单，但不能简单。

根据您所使用的数据库引擎的类型，您必须为这些类提供的SQL存在差异，因此即使您设法编写所有代码来使用这些接口，您仍然需要编写多组SQL

或者，您也可以像我们所做的那样，编写我们自己的层来处理我们使用的所有语法，这些语法不是由不同引擎提供的所有语法，但足以编写一个在执行之前被正确重写的SQL

基本上，我们已经创建了一个函数语法，在函数名前面加上

SQL:：

，这样代码就可以识别需要重写的特殊函数。然后解析出这些参数，并正确地重写它们，甚至在必要时交换参数顺序

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

此外，SQL Server的参数写为@name，其中OleDb使用位置（只需在需要参数的位置添加一个？即可），我们的代码也会处理这些差异

---

从某种意义上说，我们不太担心需要编写的SQL。

需要考虑的一件事是您切换数据库的实际可能性。在大多数情况下，这永远不会发生。即使是这样，也将是一次重大的重写，即使您使用的类与数据库无关。在这种情况下，最好使用更丰富的功能，这将帮助您更快地完成项目

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

---

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

我写了一些类似于lassevk所说的内容，但他在这方面击败了我

---

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

您应该尝试编写代码，而不依赖于数据库。也许您现在觉得它没有什么用处，但将来您可能会利用它。

看看Microsoft的模式和实践组的企业库。 他们那里的数据访问代码显示了提供者独立性的一些良好实现

---

数据库对象至少需要“调整”。但是我没有在SQL中考虑优化和特定于供应商的关键字。另外，在您提到的语法层中，这会编写SQL吗？如果是这样的话，有没有回报，我以前从来没有得到过回报