DataTable的选择VS LINQ选择

Question

时DataTable.Select应在内存中的数据表打交道时使用与LINQ Select上有何建议？

我发现LINQ语法更简单也更强大，但我不确定是否有性能或其他问题使DataTable选择更可取。

（我使用的是第三方API，它提供的是已经从数据库中预先填充的DataTable。我需要的是进一步筛选的内存。）

Answer 1

基于个人经验，我尽量避免使用Datatable.Select。我觉得它很慢，有一些奇怪的错误。

我遇到的一个（由Microsoft确认并记​​录在案的）bug是因为DataTable.Select并不总是在语句中有括号时正确计算AND条件。

例如，（Col1> 1）AND（Col < 10）可能无法返回正确的答案，而Col1> 1 AND Col < 10将无法​​正常工作。

这个错误不会显示在每台计算机上。在我的情况下，我使用的支票在我的开发平台和除一个之外的每台客户端计算机上运行良好。在发现这个错误后，我开始转向使用LINQ进行选择，并注意到操作速度显着提高。

附注：不用长时间解释，我的公司不使用数据库来存储数据。 我们使用DataTable的操作的所有都涉及从平面文件加载的内存表。所以我不是在谈论LINQ 2 SQL，而是LINQ to Dataset。

Answer 2

嗯，你跟LINQ to SQL比较数据集？如果你是，那么我会说只是沟数据集和L2S。 DataTable.Select假定您已经用数据填充了数据表。这可能会导致设计不佳，因为您需要加载的数据超过您的需求，只能在客户端进行过滤。让SQL Server为你查询，并处理它给你的结果集。只有在迭代集合时，L2S才会从数据库中读取数据，因此在之前创建查询要容易得多。

LINQ to SQL引入了一些调试开销，因为从动态生成的SQL中取出动态生成的SQL可能很尴尬（而在数据集中，您首先提供了SQL），但在几乎所有其他情况下，优雅。 deferred loading功能特别有用。

如果你不使用数据库，那么我仍然更喜欢数据集中的LINQ（在这种情况下特别称为LINQ to Objects）。语法就简单多了，因为没有魔术字符串（即SQL语句），所以测试起来更容易，而且编译时会出现拼写错误等警告。

Answer 3

甚至没有提到LINQ，我不会使用DataTable。除非我绝对必须选择，因为在大多数情况下，这意味着在客户端执行应该可能在数据库中执行的操作。

更新：我在这里的答案可能有点夸大了。有是有时合法的理由使用DataTable作为（希望）小的内存数据库，最大限度地减少客户端到数据库的往返行程。