.net - IdbConnection 与 SqlConnection

Question

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

但是，我看到的所有代码似乎都使用 System.Data.SqlClient 命名空间类或其他供应商特定类。在杂志和书籍中，很容易将其归结为 Microsoft 的影响力和他们的营销策略，只针对 SQLServer 进行编程。但它看起来就像我看到的几乎所有 .NET 代码都使用 SQLServer 特定类。

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

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

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

编辑:总结下面的一些答案，并提出我在阅读它们时的一些想法。

使用接口(interface)实现供应商中立性的可能陷阱:

嵌入的供应商特定关键字
你的 SELECT 语句(我所有的 ins，
upd 和 del 都在 procs 中，所以这是
没问题)

直接绑定(bind)
数据库可能会导致
问题。

除非你的连接
实例化是集中的，
供应商特定类将需要
无论如何都会被调用。

使用接口(interface)的积极原因:

根据我的经验，能力(甚至
如果不行使)移动到
不同的供应商一直是
受到客户的赞赏。

在可重用代码库中使用接口(interface)

Answer 1

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

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

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