我想我们将在未来的几年里就什么是最好的数据访问接口而讨论一番。因为ADO.NET并不支持基于COM的ADO（我把它叫做ADOc）支持的所有功能，开发者们不得不作出一个重大的选择。我过去的九个月里就在写一本叫做“ADO.NET和ADO例程及最佳数据库访问方式（Apress出版社）”的书，在这本书中我将帮助开发者们作出这个选择。
目前开发者们能够使用ADOc并获得对服务端的乐观算法或者悲观算法实现的游标以及静态的，基于关键字的，动态的或者离线的（批处理优化的）游标实现。在ADO.NET中他们能够选择通过DataSet使用优化的同步访问或者使用底层的（并且更快速的）DataReader来返回一个“实时”的数据流。
使用ADOc的问题是我觉得其性能会有所降低因为每次对非受控代码（unmanaged）MDAC DLL（ADO）的访问将两次经历一个叫做COM Interop的翻译过程--一次是发送请求而另一次是从MDAC返回数据。ADOc方式还依赖于我称之为OSFA（one size fits all一次调用，全部满足）的数据接口，比方OLE DB。
是的，ADO.NET提供了它自己的OSFA OleDb.Net Data Provider，但是它也实现了新的SqlClient 数据提供程序它直接使用TDS。这是从DB-Library（以及VBSQL）出现以来出现的第一个TDS。这个（全新）的数据访问方法将解放开发者访问数据的方式。是的，它只能在SQL Server上工作。但是这并不意味着其它的销售商（或者微软）不会创建其它的“原始”的数据访问接口来获得比OLE DB或者ODBC更好的性能。
假设你能够容忍缺少ADOc诸如keyset 游标和悲观锁定算法这样的功能。那么你是不是就应该使用DataSet或者DataReader来管理你的数据呢？实际上DataSet使用DataReader来进行底层的I/O。DataReader是一个非常简单但是非常快速的接口。它每次提供一行数据。虽然你能够把单个的数据行放到一个数组里，但是你并不会想这么做因为这需要额外的工作和性能上的损失。这意味着你需要每次一行进行遍历而且每一行都是使用特定数据类型的Get语句获得的。
即使是对于所有这些代码，数据提取过程，使用DataReader还是比用来填充由DataSet管理的DataTables的Fill方法要快。之所以这样说是因为DataSet比ADOc Recordset复杂上好几个数量级也更加灵活而且强大。它能够轻易的处理级联数据（不需要特别的Shape语句）并能够无缝的绑定到复杂的控件。它还能够通过由开发者定义的包含了适当的UPDATE,DELETE,和INSERT SQL语句或者存储过程的Command对象来修改数据。
是的，只要还有许多新的，到今天还没有测试过的应用程序来最大化的利用这套新的数据访问技术，那么争论就会继续下去。
