对于混合托管/非托管应用程序，经典 ADO 是否仍然可行？答案

【问题标题】：Is Classic ADO still viable for a mixed managed/unmanaged App?对于混合托管/非托管应用程序，经典 ADO 是否仍然可行？
【发布时间】：2010-03-12 08:08:12
【问题描述】：

我们有一个复杂的架构，在需要数据库访问的非托管代码中有很多逻辑。

目前这是通过 ODBC 驱动程序和 MFC 类实现的，我们正在考虑将抽象层迁移到使用 ADO 或 ADO.Net 的问题。在后一种情况下，我们必须将数据库逻辑推回 .Net 层。我正在尝试确定通过 .Net 回调调用数据库的痛苦是否被 ADO.Net 中的改进所抵消。

Wikipedia comparison 很有趣，尽管我不确定我是否相信比较表中的所有要点（例如：ADO.Net 是否总是使用 XML 来传递数据？）。

2005 comparison 显示 ADO.Net 的执行速度明显更快。

Microsoft 的guide to ADO.Net for ADO programmers 建议我们从使用 ADO.Net 中获益良多，尤其是数据以原生 (.Net) 类型而不是仅通过 OLEAutomation 的 Variant 提供的方式。

【问题讨论】：

【解决方案1】：

eg: does ADO.Net always use XML to pass data?

没有。听起来像维基百科中的白痴信息。

2 种选择。首先，我真的会摆脱 ODBC - 并至少转向 OleDb 驱动程序。如果可能（告诉我 - 我有一个 .NET 应用程序，它使用 ODBC 驱动程序调用 JDBC ddriver 来调用第三方应用程序服务器）。

现在，您可以双向使用——ADO 在两侧、托管 ADO.NET 和从 NET 层公开——但这实际上不是程序员的决定，而是应该在主要上下文中看到的架构问题。我可能会选择 .NET 层，可能同时带有 OData 暴露层，并尝试从非托管层使用它。

【讨论】：