真正通用的数据链路在哪里？
在过去的 oledb 时代，我使用 UDL 文件和相关向导来检查和创建连接字符串。如今，您可以通过这种方式创建的连接字符串不再那么通用了。例如，ADO.NET 实体框架创建 UDL 向导无法处理的修饰连接字符串。有没有任何工具可以创建当今的通用数据链接？
In the good old oledb times I used UDL files and the related wizard to check and create connection strings. Nowadays the connection strings you can create this way aren’t that universal any more. The ADO.NET Entity Framework for example creates decorated connection strings which the UDL wizard can’t handle. Is there any tool to create the universal data links of today?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为以下两者之间存在区别：
今天的（即：.NET？）连接字符串并不比 OleDb 连接字符串通用。它们始终特定于给定的提供商。键/值对可能不相同，但概念始终存在。
UDL 工具使用 COM 对象工作，并且仍然可以使用。例如，可以为实体框架连接字符串的 UDL 工具编写扩展。以下是官方参考的链接：Provider Extensible Data Link用户界面 API
.UDL 文件仍然可以在 .NET（使用 P/Invoke）中使用 IDBPromptInitialize 和 IDataInitialize OleDb 的接口使用，尽管我同意，但现在看起来并不那么自然:)
I think there is a difference between:
Today's (ie: .NET?) connection strings are not less universal than OleDb connection strings. They are always specific for a given provider. The key/value pairs may not be the same, but the concept is always there.
The UDL tool works using COM objects and can still be used. For example, one could write an extension to the UDL tool for Entity Framework connection strings. Here is a link on the official reference: Provider Extensible Data Link User Interface API
.UDL files are still usable in .NET (with P/Invoke) using IDBPromptInitialize and IDataInitialize OleDb's interfaces, although I agree, it does not seem so natural these days :)
通用的“数据链路”无法支持所有数据库供应商/版本的所有功能，大多数软件是由企业内部编写的，用于与其对话在内部数据库中，因此不需要独立于数据库。
如果 API 与您选择的数据库提供的功能不匹配，则很难对其进行编码，因为文档似乎与您尝试使用的数据库不匹配。
Microsoft 现在希望数据库供应商为数据库提供 Ado.net 数据访问支持，因此每个数据库的数据访问往往不同 - 但大多数人并不关心，因为那里的代码只需要与单一数据库供应商。
有 3rd 方选项，例如 devArt 的 dotConnect 和 DataDirect 为 .net 提供通用“数据链接”，但需要付费。
nHibernate 将位于大多数供应商 .net 数据库访问层之上并隐藏大部分差异如果您乐意使用 ORM。
A universal “data link” cannot support all functions of all databases vendors/versions, most software is written in house by corporations to talk to their in house databases, so don’t need to be database independent.
It is harder to code against an API that is not a good match for the functions your chosen database provides as the documentation never seems to match the database you are trying to use.
Microsoft now expect the database vendor to provide the Ado.net data access support for the database, hence the data access tends to be different for each database – but most people don’t care as there code only needs to work with a single database vender.
There are 3rd party options like, devArt's dotConnect and DataDirect that provides a universal “data link” for .net but at a price.
nHibernate will sit on top of most of the venders .net database access layer and hide most of the differences if you are happy to use a ORM.