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