Любые советы о том, когда DataTable.Select следует использовать вместо LINQ Выбрать при работе с таблицей данных в памяти?
Я нахожу синтаксис LINQ более простым и мощным, но я не уверен, есть ли производительность или другие проблемы, которые делают выбор DataTable предпочтительным.
(Я использую сторонний API, который предоставляет DataTable, который был предварительно заполнен из базы данных. Мне нужно отфильтровать его в памяти.)
Основываясь на личном опыте, я стараюсь избегать Datatable.Select. Я считаю, что это медленно и имеет некоторые странные ошибки.
Одна (подтвержденная и задокументированная Microsoft) ошибка, с которой я столкнулся, заключалась в том, что DataTable.Select не всегда правильно оценивает условия AND, когда в операторе есть скобки.
Например, (Col1 > 1) AND (Col ‹ 10) может не дать правильных ответов, тогда как Col1 > 1 AND Col ‹ 10 будет работать правильно.
Эта ошибка проявляется не на каждом компьютере. В моем случае проверка, которую я использовал, работала нормально на моей платформе разработки и на всех клиентских компьютерах, кроме одного. После того, как я обнаружил эту ошибку, я начал переходить на использование LINQ для выбора и заметил значительное увеличение скорости операций.
Примечание: не вдаваясь в длинные объяснения, моя компания не использует базу данных для хранения данных. Все наши операции с DataTables связаны с таблицами памяти, загружаемыми из плоских файлов. Так что я говорю не о LINQ 2 SQL, а о LINQ to Dataset.
Даже не упоминая LINQ, я бы не стал использовать DataTable.Select где-либо, если только мне это абсолютно не нужно, поскольку в большинстве случаев это означает выполнение в клиенте того, что, вероятно, должно быть выполнено в базе данных.
Обновление: мой ответ здесь, вероятно, немного преувеличен. Иногда существуют законные причины для использования DataTable в качестве (надеюсь) небольшой базы данных в памяти, которая сводит к минимуму круговые пути от клиента к базе данных.
Хм, вы сравниваете наборы данных с LINQ to SQL? Если да, то я бы посоветовал просто отказаться от наборов данных и перейти на L2S. DataTable.Select предполагает, что вы уже заполнили таблицу данных данными. Это может привести к плохому дизайну, когда вы загружаете больше данных, чем вам нужно, просто для фильтрации в клиенте. Заставьте SQL Server выполнять запросы за вас и работать с набором результатов, который он вам даст. L2S будет считывать данные из базы данных только при повторении коллекции, поэтому гораздо проще формулировать запросы до обращения к базе данных.
LINQ to SQL вводит некоторые накладные расходы на отладку, потому что может быть неудобно извлекать из него динамически сгенерированный SQL (тогда как в наборах данных вы в первую очередь предоставляете SQL), но почти во всех других ситуациях это гораздо более элегантно. Функция отложенной загрузки особенно полезна.
Если вы не работаете с базой данных, я бы предпочел LINQ (известный как LINQ to Objects в этом сценарии) по наборам данных. Синтаксис просто намного проще, и поскольку нет магических строк (т.е. операторов SQL), его легче тестировать, и вы получаете предупреждения во время компиляции для опечаток и т. д.
