关于在处理内存中的 DataTable 时应该使用 DataTable.Select 还是使用 LINQ Select 有什么建议吗？
我发现 LINQ 语法更简单、更强大，但我不确定是否存在性能或其他问题使 DataTable 选择更可取。
（我正在使用第三方 API，该 API 提供已从数据库预填充的 DataTable。我需要在内存中进一步过滤。）
【问题讨论】：
标签： .net linq ado.net datatable linq-to-objects
根据个人经验，我尽量避免使用 Datatable.Select。我发现它很慢并且有一些奇怪的错误。
我遇到的一个（由 Microsoft 确认并记录的）错误是，当语句中有括号时，DataTable.Select 并不总是正确评估 AND 条件。
例如，(Col1 > 1) AND (Col 1 AND Col
此错误不会出现在每台计算机上。在我的情况下，我使用的检查在我的开发平台和除一台之外的每台客户端计算机上运行良好。在我发现这个错误后，我开始转向使用 LINQ 进行选择，并注意到操作速度显着提高。
旁注：无需过多解释，我的公司不使用数据库来存储数据。 所有我们对 DataTables 的操作都涉及从平面文件加载的内存表。所以我说的不是 LINQ 2 SQL，而是 LINQ to Dataset。
【讨论】：
即使不提及 LINQ，我也不会使用 DataTable.Select anywhere，除非我绝对必须这样做，因为在大多数情况下，这意味着在客户端执行一些可能应该在数据库中执行的操作。
更新：我的回答可能有点夸大了。 有时有正当理由将 DataTable 用作（希望）小型内存数据库，以最大限度地减少客户端到数据库的往返行程。
【讨论】：
嗯，您是在将数据集与LINQ to SQL 进行比较吗？如果你是，那么我会说只是放弃数据集并使用 L2S。 DataTable.Select 假设您已经用数据填充了数据表。这可能会导致糟糕的设计，您加载的数据超出您的需要，只是为了在客户端进行过滤。让 SQL Server 为您进行查询，并处理它为您提供的结果集。只有在您迭代集合时，L2S 才会从数据库中读取数据，因此在在访问数据库之前制定查询要容易得多。
LINQ to SQL 引入了一些调试开销，因为从中获取动态生成的 SQL 可能很尴尬（而在数据集中，您首先要提供 SQL），但在几乎所有其他情况下，它要优雅得多. deferred loading 功能特别有用。
如果您不使用数据库，那么我仍然更喜欢 LINQ（在这种情况下特别称为 LINQ to Objects）而不是数据集。语法更简单，并且因为没有魔术字符串（即 SQL 语句），所以更容易测试，并且您会收到拼写错误等的编译时警告。
【讨论】：