LINQ to SQL против ADO.NET - что быстрее?

Question

Поскольку LINQ to SQL в основном представляет собой слой поверх ADO.NET, он требует некоторого перевода. Значит ли это, что прямое использование ADO.NET быстрее, чем LINQ? Или разница настолько мала, что не имеет значения?

Answer 1

Это означает, что ADO.NET быстрее. Это также дает вам больше свободы для оптимизации ваших запросов SQL (технически вы могли бы использовать LINQ to SQL только с хранимыми процедурами, но при этом не могли бы упустить весь смысл).

Дело в том, что если вам действительно действительно нужно оптимизировать для лучшей производительности, то никто не рекомендует использовать OR / M. Есть куча соображений относительно OR / M: с точки зрения производительности. Но многим сайтам на самом деле не нужно оптимизировать , что для производительности, во многом так же, как мы можем позволить себе программирование на .NET, а не на ассемблере, даже если это такая же нагрузка по сравнению с писать код на языке более низкого уровня.

Смысл использования LINQ to SQL, NHibernate или любого другого OR / M заключается в том, что (как и в случае аналогии с .NET) это даст вам много удобства и сэкономит вам много времени. время разработки и сделать рефакторинг и другие более поздние изменения намного более простой задачей.

Answer 2

В исполнении это немного медленнее. Однако Linq to SQL экономит время разработчика, что является его главным преимуществом, ИМХО.

Доброжелательность,

Dan

Answer 3

Технически, да, есть некоторые издержки, и Linq2Sql может иногда генерировать немного менее оптимальный SQL, но если вы не выполняете работу с высокой производительностью или высокой пропускной способностью, вы, вероятно, вряд ли заметите это.

Мой совет - выбрать технологию DA, которая больше всего соответствует вашим требованиям, и идти с ней. Помните преимущества таких вещей, как Linq2SQL или EF уменьшается время, потраченное на написание разработчик повторяющихся слоев DA, ​​и уменьшить код (так что в теории возможно, уменьшенные ошибки и меньше обслуживания - хотя это спорно). Затем профилируйте производительность и, если вы обнаружите «бутылочную горлышко», вы можете начать оптимизировать конкретные запросы, а затем, если это абсолютно необходимо, очень важные запросы, которые вызывают большие «бутылочные горлышки», могут быть преобразованы в обычные ado.net

Answer 4

Это правда, что LINQ to SQL - это слой поверх ADO.NET.Но есть и другие варианты, которые позволяют хранить результаты в памяти.Если ваше намерение состоит в том, чтобы воздействовать на данные сразу после извлечения, лучше работать с ADO.NET DataReader в цикле для повышения производительности.Тем не менее, если вам необходимо выполнить дальнейшую обработку данных, вам нужно будет хранить их в памяти, используя какую-то переменную, такую ​​как объект LINQ to SQL или DataTable.Обе эти переменные памяти в основном генерируются одинаково под крышками.Учитывая этот факт, я бы сказал, что скорость, с которой каждая опция доступна в памяти, не так важна, как вы планируете работать с данными.