我正在与另一位与我一起工作的程序员进行辩论。
对于数据库返回类型，是否存在任何显着的内存使用或性能差异，或其他应使某人避免使用 DataSets 和 DataTables 并偏爱实现IEnumerable<T>...的类型或反之亦然的缺点
我更喜欢返回实现IEnumerable<T>( List<T>, T[] etc) 的类型，因为它更轻量级，在访问属性时对对象进行强类型化，允许有关底层类型的更丰富的信息等。尽管手动使用数据读取器时，它们确实需要更多时间来设置。
这些天使用 DataTables 的唯一原因仅仅是懒惰吗？
DataTables 肯定比 Lists 重得多，无论是在内存需求方面，还是在创建/填充它们所花费的处理器时间方面。
使用 DataReader 比使用 DataTables 快得多（虽然更冗长）（我假设您正在使用 DataAdapter 来填充它们）。
也就是说......除非这是在某个真正重要的地方，否则你可能会很好，两种方法都足够快，所以在每种情况下都选择更舒服的方法。（有时你想用很少的代码来填充它们，有时你想用很少的代码来阅读它们）
我自己倾向于只在绑定到 GridView 时使用 DataTables，或者当我需要同时激活多个结果集时。
使用 System.Collections 类的另一个优点是您可以获得更好的排序和搜索选项。我不知道有任何合理的方法可以改变 DataTable 的排序或搜索方式；使用集合类，您只需让您的类实现 IComparable 或 IEquatable，您就可以完全自定义 List.Sort 和 List.Contains 的工作方式。
此外，对于列表，您不必担心 DBNull，它不止一次让我绊倒，因为我期待 null 并得到了 DBNull。
我还喜欢这样一个事实，IEnumerable<T>即您可以使用方法和属性来增强集合的底层类型，这使得实现更加优雅，代码更易于维护。例如 FullName 属性。如果您无法控制，您还可以向该类添加扩展方法。
public class SomeUser
{
public string FirstName { get; set; }
public string LastName { get; set; }
public string FullName { get { return String.Format("{0} {1}", FirstName, LastName); } }
}
直接使用 DataTables 意味着将自己绑定到底层数据源及其布局方式。从可维护性的角度来看，这并不好。如果您的视图需要的只是一些对象的列表，那么您应该提供的就是这些。
我发现通过 sql 使用大表，数据表比 IEnumerable 快得多。我在一个 HTML 页面中转储了一个包含 26k 行和 25 列的表。数据表用了 3 秒，IEnumerable 用了 9 秒。我投票给数据表。除类型外，所有代码相同。