代码之家 › 专栏 › 技术社区 › John MacIntyre

IdbConnection与SqlConnection

vendor-neutrality design-decisions .net

John MacIntyre · 技术社区 · 17 年前

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

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

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

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

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

嵌入在中的特定于供应商的关键字 (没问题)
直接绑定问题。
除非你的连接特定于供应商的类将需要

根据我的经验,这种能力(甚至如果未行使)移动到
在可重用代码库中使用接口

6 回复 | 直到 17 年前

Kibbee 17 年前

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

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

Lasse V. Karlsen 17 年前

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

基本上,我们已经创建了一个函数语法,在这个语法中,我们用 SQL:: ,这使我们的代码能够识别需要重写的特殊函数。然后解析出这些参数,并正确地重写它们,甚至在必要时交换参数顺序。

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

我们不太担心需要编写的SQL,这是值得的。

Joel Coehoorn 17 年前

我写的东西和拉塞夫克说的差不多,但他抢先一步。

Santiago Corredoira 17 年前

您应该试着编写代码数据库不可知。也许你现在不觉得它有用,但你将来可能会利用它。

Andrew Rollings 17 年前

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

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

Tristan Warner-Smith 17 年前

http://msdn.microsoft.com/en-us/library/cc467894.aspx