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