IdbConnection 与 SqlConnection
当我编写应用程序时，我使用 System.Data 接口（IDbConnection、IDbCommand、IDataReader、IDbDataParameter 等）。 我这样做是为了减少供应商依赖性。 除非我正在做一个简单的测试应用程序，否则在咨询时这似乎是合乎道德的事情。
但是，我看到的所有代码似乎都使用 System.Data.SqlClient 命名空间类或其他供应商特定的类。 在杂志和书籍中，很容易将其归因于 Microsoft 的影响力及其仅针对 SQLServer 进行编程的营销策略。 但看起来我看到的几乎所有 .NET 代码都使用 SQLServer 特定的类。
我意识到供应商特定的类具有更多功能，例如，向 SqlCommand 对象添加参数是一种方法，而将其添加到 IDbCommand 则是令人恼火的 4 行以上代码。 但话又说回来; 针对这些限制编写一个小帮助器类非常简单。
我还想知道当 SQLServer 是当前目标客户端时针对接口进行编程是否是过度设计，因为并不立即需要它。 但我认为并非如此，因为针对接口进行编程的成本是如此之低，而减少供应商依赖性却提供了如此巨大的好处。
您是否使用供应商特定的数据类或接口？
编辑：总结下面的一些答案，并加入我在阅读它们时的一些想法。
使用接口实现供应商中立性的可能陷阱：
- 嵌入的供应商特定关键字 你的 SELECT 语句（我所有的ins， 更新，& del 在 procs 中，所以那就是 不是问题）
- 直接绑定 数据库可能会导致 问题。
- 除非你的连接 实例化是集中式的， 供应商特定类需要 无论如何都会被召唤。
使用接口的积极原因：
- 根据我的经验，这种能力（甚至 如果没有行使）移动到 不同的供应商一直 受到客户的赞赏。
- 使用可重用代码库中的接口
When I write an app, I use the System.Data interfaces (IDbConnection, IDbCommand, IDataReader, IDbDataParameter, etc...). I do this to reduce vendor dependencies. Unless, I'm doing a simple test app, it just seems like the ethical thing to do when consulting.
However, it seems like all the code I see uses the System.Data.SqlClient namespace classes or other vendor specific classes. In magazines and books it's easy to chalk this up to Microsoft influence and their marketing spin to program only against SQLServer. But it seams like almost all the .NET code I see uses the SQLServer specific classes.
I realize the vendor specific classes have more functionality, for example adding a parameter to a SqlCommand object is one method, where as adding it to an IDbCommand is an irritating 4+ lines of code. But then again; writing a little helper class for these limitations is pretty simple.
I've also wondered if programming against the interfaces when SQLServer is the current target client is over-engineering since it is not required immediately. But I don't think it is since the cost of programming against the interfaces is so low, where as reducing vendor dependency provides such a huge benefit.
Do you use vendor specific data classes or the interfaces?
EDIT: To summarize some of the answers below, and throw in some thought's I had while reading them.
Possible pitfalls to using interfaces for vendor neutrality:
- Vendor specific keywords embedded in
your SELECT statements (all my ins,
upd, & del's are in procs, so that's
not a problem) - Binding directly the
database would probably cause
issues. - Unless your connection
instantiation is centralized, the
vendor specific class will need to
be called anyway.
Positive reasons to use interfaces :
- In my experience the ability (even
if not exercised) to move to a
different vendor has always been
appreciated by the customer. - Use interfaces in reusable code libraries
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
需要考虑的一件事是您切换数据库的实际机会。 在大多数情况下，这永远不会发生。 即使确实如此，即使您使用与数据库无关的类，这也将是一次重大重写。 在这种情况下，最好使用功能更丰富的选项，并帮助您更快地完成项目。
话虽这么说，我认为在大多数情况下，您应该在实际的 .Net API 之上使用您自己创建的层，这样，如果您必须更改必须使用的类，那么就不会那么麻烦了。一个问题。 即使您保留在同一个数据库上，您也永远不知道什么时候必须切换访问数据库的方式。 任何从 ASP 迁移到 ASP.Net（ADODB 与 ADO.Net）的人都可以告诉您这是多么痛苦。
所以我认为最好的解决方案是使用功能更丰富的数据库特定 API，并在其之上构建您自己的层，以便您可以在必要时轻松交换它。
One thing to take into consideration is the actual chance that you will ever switch databases. In most cases, this will never happen. And Even if it does, it will be a major rewrite, even if you use classes that are database neutral. In this case, it's probably just best to use whichever is more feature rich and will help you get the project done quicker.
That being said, I think that in most instances, you should use a layer you create yourself, above the actual .Net API, so that if you ever have to change which classes you have to use then it won't be so much of a problem. Even if you stay on the same database, you never know when you'll have to switch the way you access the database. Anybody who migrated from ASP to ASP.Net (ADODB vs. ADO.Net) can tell you how much of a pain this is.
So I think the best solution is to use the more feature rich database specific API, and build you own layer on top of it, so that you can easily swap it out if necessary.
您必须为类提供的 SQL 存在差异，具体取决于您所使用的数据库引擎的类型，因此即使您设法编写所有代码来使用接口，您仍然需要编写多组SQL。
或者，您可以做我们已经做过的事情，编写我们自己的层来处理我们使用的所有语法，这不是不同引擎提供的所有语法，但足以编写一个之前被正确重写的 SQL执行。
基本上，我们创建了一个函数语法，在函数名称前面加上
SQL::前缀，这让我们的代码能够识别需要重写的特殊函数。 然后将它们解析出来并正确重写，甚至在必要时交换参数顺序。可以完成诸如返回当前服务器日期和时间的函数名称之类的小事情，也可以完成更大的事情，比如如何选择查询的前 N 行。
此外，SQL Server 的参数写为 @name，其中 OleDb 使用位置（只需在需要参数的位置添加 ? ），我们的代码也会处理这些差异。
从某种意义上说，它是有回报的，因为我们不必太担心需要编写的 SQL。
There are differences to the SQL you're going to have to give the classes, depending on the type of database engine you're talking to, so even if you manage to write all your code to use the interfaces, you still need to write multiple sets of SQL.
Or, you can do what we have done, write our own layer that takes care of all the syntax we use, which isn't all the syntax provided by the different engines, but enough to manage to write one SQL that gets properly rewritten before execution.
Basically we've created a function syntax where we prefix the names of the functions with
SQL::, which lets our code identify the special functions that needs to be rewritten. These are then parsed out, and rewritten properly, even so far as to swap around argument order if necessary.Small things like the name of the function that returns the current server date and time can be done, but also bigger things, like how to select the first N rows of a query.
Additionally, parameters for SQL Server is written as @name, where OleDb uses positional (just add a ? where you want the parameter), and our code handles those differences as well.
It pays off in the sense that we don't worry much about the SQL that needs to be written.
我正在写一些类似于拉塞夫克所说的东西，但他抢先了我。
此外，您必须在某个时刻与真实的数据库进行对话。 您也许能够用接口代码包装大部分数据访问，这是一个好主意。 但最终，如果您使用 SQL Server，您将需要创建 SqlClient.SqlConnection 的真实实例。 对于 Access、Oracle 或 MySQL 也是如此。
I was writing something similar to what lassevk said, but he beat me to it.
Additionally, you have to talk to a real database at some point. You might be able to get away wrapping most of your dataaccess with interface code, and that's a good idea. But eventually if you're using SQL Server you'll want to create a real instance of SqlClient.SqlConnection. Same for Access, Oracle, or MySQL.
您应该尝试编写与数据库无关的代码。 也许您现在不觉得它有用，但将来您可能会利用它。
You should try to write your code database agnostic. Maybe you don't find it useful right now but you will probably take advantage of it in the future.
我使用供应商特定的类来进行直接数据库工作（除非我被告知我们最终可能会使用不同的数据库 - 发生的次数：一次）。
但是，如果我最终将一些非数据库特定代码分解为单独的类，我通常会创建方法参数接口 - 特别是如果我认为它在其他项目中有用，并且我不依赖于任何特定的直接访问类的特征。
基本上，套用爱因斯坦的话：让解决方案尽可能简单，但不能更简单。
I use the vendor specific classes where I'm doing direct db work (unless I'm told it's a possibility we may end up using a different database - number of times that has happened: once).
However if I end up factoring off some non-db specific code into separate classes, I'll often make the method parameters interfaces - especially if I think it will be useful in other projects, and I'm not relying on any of the specific features of the direct access class.
Basically, to paraphrase Einstein: Make the solution as simple as possible, but no simpler.
查看 Microsoft 的模式和实践小组的企业库。
他们那里的数据访问代码显示了提供者独立性的一些良好实现。
http://msdn.microsoft.com/en-us/library/cc467894。 ASPX
Take a look at Microsoft's Patterns and Practices group's Enterprise library.
The data access code they have there shows some good implementations of provider independence.
http://msdn.microsoft.com/en-us/library/cc467894.aspx