Question

我和我合作的另一位程序员正在讨论。

对于数据库返回类型，是否有任何重要的内存使用或性能差异，或其他缺点应该使某人避免使用DataSet和DataTables并支持实现IEnumerable<T>的类型...反之亦然

我更喜欢返回实现IEnumerable<T>（List<T>, T[] etc）的类型，因为它更轻量级，在访问属性时对对象强类型化，允许有关底层类型等的更丰富信息。它们确实需要更多时间手动使用数据读取器时设置。

这一天使用DataTables的唯一理由是懒惰吗？

Answer 1

DataTables肯定比列表重得多，无论是在内存要求方面，还是在创建它们/填充它们的处理器时间方面。使用DataReader比使用DataTables要快得多（虽然更冗长）（我假设您正在使用DataAdapter来填充它们）。

那说...... 除非在某些地方真的很重要，否则你可能都很好，两种方法都足够快，所以只要选择更适合每种情况的方法。（有时你想用很少的代码填充它们，有时你想用很少的代码读它们）

当我绑定到GridView时，或者当我需要同时激活多个结果集时，我自己只会使用DataTable。

Answer 2

使用System.Collections类的另一个好处是可以获得更好的排序和搜索选项。我不知道有任何合理的方法来改变DataTable的排序或搜索方式;使用集合类，您只需要实现IComparable或IEquatable，就可以完全自定义List.Sort和List.Contains的工作方式。

另外，对于列表，您不必担心DBNull，因为我期待null并得到DBNull，因此我不止一次将我绊倒。

Answer 3

我也喜欢使用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); } }
}

Answer 4

直接使用DataTables意味着将自己与底层数据源及其布局方式联系起来。从可维护性的角度来看，这并不好。如果您的所有视图需求都是某些对象的列表，那就是您应该提供的所有内容。

Answer 5

我通过sql找到大表，数据表比IEnumerable快得多。我在一个HTML页面中丢弃了一个包含26k行，25列的表。数据表在3秒内，IEnumerable花了9秒。我投票给DataTable。除类型外，所有代码都相同。

DataTables与IEnumerable <t> </t>

5 个答案: