当我编写应用程序时,我使用 System.Data 接口(IDbConnection、IDbCommand、IDataReader、IDbDataParameter 等...)。我这样做是为了减少对供应商的依赖。除非,我正在做一个简单的测试应用程序,否则在咨询时这似乎是合乎道德的事情。
但是,我看到的所有代码似乎都使用 System.Data.SqlClient 命名空间类或其他供应商特定类。在杂志和书籍中,很容易将其归结为 Microsoft 的影响力和他们的营销策略,只针对 SQLServer 进行编程。但它看起来就像我看到的几乎所有 .NET 代码都使用 SQLServer 特定类。
我意识到供应商特定的类具有更多功能,例如向 SqlCommand 对象添加参数是一种方法,而将其添加到 IDbCommand 是令人讨厌的 4 多行代码。但话又说回来; 为这些限制编写一个小助手类非常简单。
我还想知道当 SQLServer 是当前目标客户端时针对接口进行编程是否过度设计,因为它不是立即需要的。但我不认为这是因为针对接口进行编程的成本如此之低,因为减少供应商依赖性提供了如此巨大的好处。
您是否使用供应商特定的数据类或接口?
编辑:总结下面的一些答案,并提出我在阅读它们时的一些想法。
使用接口实现供应商中立性的可能陷阱:
- 嵌入在您的 SELECT 语句中的供应商特定关键字(我所有的 ins、upd 和 del 都在 procs 中,所以这不是问题)
- 直接绑定数据库可能会导致问题。
- 除非您的连接实例化是集中式的,否则无论如何都需要调用供应商特定的类。
使用接口的积极原因:
- 根据我的经验,客户一直很欣赏转移到不同供应商的能力(即使没有行使)。
- 在可重用代码库中使用接口