DataTables vs IEnumerable
我正和另一位与我合作的程序员进行辩论。
对于数据库返回类型，是否有任何重要的内存使用或性能差异，或其他缺点应该使某人避免使用DataSets和DataTables并支持实现IEnumerable类型…反之亦然
我更喜欢返回实现IEnumerable （ List, T[] etc ）的类型，因为它更轻量级，在访问属性时对对象强类型，允许有关底层类型的更丰富信息等。它们需要更多时间设置虽然手动使用数据读取器。
这些日子使用DataTables的唯一理由就是懒惰吗？
DataTables肯定比Lists重得多，无论是在内存要求方面，还是在创建它们/填充它们的处理器时间方面。
使用DataReader比使用DataTables要快得多（虽然更冗长）（我假设您正在使用DataAdapter来填充它们）。
那就是说……除非这个地方真的很重要，否则你可能都很好，而且两种方法都足够快，所以在每种情况下都可以选择更舒适的方法。 （有时你想用很少的代码填充它们，有时你想用很少的代码读它们）
我自己倾向于仅在绑定到GridView时使用DataTables，或者当我需要同时激活多个结果集时。
使用System.Collections类的另一个好处是可以获得更好的排序和搜索选项。 我不知道改变DataTable排序或搜索方式的任何合理方法; 您可以使用集合类实现IComparable或IEquatable，并且可以完全自定义List.Sort和List.Contains的工作方式。
还有列表你不必担心DBNull，因为我期待null并得到了DBNull，因此我不止一次地绊倒了我。
我也喜欢使用IEnumerable的事实，你可以使用方法和属性来增强集合的底层类型，这使得实现更加优雅，并且代码更易于维护。 例如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); } } }
直接使用DataTable意味着将自己与基础数据源及其布局方式联系起来。 从可维护性的角度来看，这并不好。 如果你的所有视图需求都是一些对象的列表，那就是你应该给它的全部内容。
我通过sql找到了大表，数据表快得多，而不是IEnumerable。 我在一个HTML页面中丢弃了一个包含26k行，25列的表。 数据表在3秒内，IEnumerable花了9秒。 我投票给DataTable。 除类型外，所有代码都相同。