关于 OLE DB 和 .NET 的思考

ADO 的编程接口比原始的 OLE DB SDK 更加丰富。虽然在 C++ 应用程序中使用 ADO 是完全可行的，但是 OLE DB 调用经过的代码层次较少，与相应的 ADO 代码相比，能更直接地到达数据。

虽然 ADO 很明显是在 OLE DB 上生成的，但是调用原始 OLE DB 接口和通过 ADO 运行时发出的调用具有不同的相对速度。这一事实导致了语言之间的差异。哪一种更好、更值得推荐呢？是 OLE DB 的 C++ 高性能层次还是 Visual Basic 组件中更简单、更友好的 ADO 模型？

除了提供者和使用者，OLE DB 模型还包括第三个元素——OLE DB 服务。服务是一种 COM 组件，用于处理返回给使用者的“行集”。它就像挂钩一样工作，监督使用者和提供者之间的所有通信。ADO 在很大程度上依赖 OLE DB 服务来添加其扩展功能，如数据塑型、持久性和断开的记录集。

因此，自从人们开始重视构建基于 COM 的分布式应用程序以来，就开发了各种针对某些特定领域的最佳实例。为改进 Web 应用程序的可伸缩性，人们转而使用数据访问断开模型。

简单说来，数据使用者和数据提供者并不总是连接的。一旦建立了连接，便可以发出指定的查询，获取记录并将其放至内存中的存储库，然后从数据源断开连接。然后您再在脱机状态下处理这些记录，并在需要时重新连接或提交更改。这一模型不是在所有情况下都可以使用，不过，一旦它发生作用，您就会发现它在可伸缩性和总体性能方面非常有价值。

许多系统已经进行了转换（或再转换），通过客户端游标服务来部署 ADO 记录集，从而启用数据断开。OLE DB 还不是专用于此类交互的模型，所以 ADO 是通过中间 OLE DB 服务进行扩展的。

由于其结构所固有的灵活性，OLE DB 可以成功地应用于断开连接方案，但是，这当然不代表最佳的工作方式。这一实现方案的另一小小的限制是：方案较多地依赖 ADO 记录集进行工作，以至于人们怀疑它不可能总是把每件事都做好。这样的对象如何才能在各种情况下成为最快的工作工具，不论是连接还是断开，有没有 XML，是创建的还是从磁盘加载的？