Плюсы и минусы LINQ (встроенный в язык запрос) - PullRequest
26 голосов
/ 07 ноября 2008
  • Каковы плюсы и минусы LINQ (Language-Integrated Query)?
  • Каковы лучшие и худшие случаи использования LINQ?
  • Какую выгоду вы получили или не получили от использования LINQ?
  • Какие источники данных получают наибольшую и максимальную выгоду от LINQ?

Ответы [ 5 ]

32 голосов
/ 07 ноября 2008

Я большой поклонник LINQ - хотя его нужно держать в перспективе, а не рассматривать как серебряную пулю.

Плюсы:

  • Декларативный подход делает запросы более понятными и более компактными
  • Расширяемость и деревья выражений позволяют в основном согласовывать запросы к нескольким источникам
  • Даже внутрипроцессные запросы могут быть реализованы другими способами, нежели LINQ to Objects - например, Параллельный LINQ и моя собственная платформа Push LINQ. Очень гибкий.
  • Сказочно полезно для обработки запросов, где легче всего разобраться
  • Замечательно иметь возможность избегать SQL в строках и т. Д.
  • Широкий спектр операторов, предоставляемых по умолчанию, и другие могут быть легко добавлены для LINQ to Objects
  • Языковые функции, представленные преимущественно для LINQ, широко применяются в других местах (yay для лямбд)

Минусы:

  • Выражения запроса недостаточно понятны и используются слишком часто. Часто простой вызов метода короче и проще.
  • Неизбежные несоответствия между поставщиками - несоответствие импеданса все еще присутствует, что является разумным, но его необходимо понять
  • Всегда будут некоторые вещи, которые вы можете делать в SQL, но не в LINQ
  • Не понимая, что происходит, очень просто написать очень неэффективный код
  • Трудно написать поставщика LINQ. Это может быть неизбежно, но мы будем признательны за дополнительные рекомендации от Microsoft.
  • Это новый способ мышления о доступе к данным для большинства разработчиков, и ему понадобится время для понимания, чтобы проскочить
  • Не конкретно LINQ, но связано с ним - способы обнаружения методов расширения в C # недостаточно детальны
  • Некоторые операторы «отсутствуют», в частности, эквиваленты OrderBy для вещей, отличных от упорядочения - например, поиск предмета с максимальной ценностью свойства
  • Отложенное выполнение и потоковая передача плохо изучены (но улучшаются)
  • Отладка может быть очень сложной из-за отложенного выполнения и потоковой передачи
  • В некоторых особых случаях LINQ может быть значительно медленнее, чем ручной код. Чем лучше вы понимаете внутреннюю работу, тем лучше вы сможете предсказать это. (И, конечно, если производительность важна для вас, вам следует провести соответствующие тесты.)

Я считаю, что лучше всего иметь дело с внутрипроцессными запросами. Их легко предсказать, понять и расширить. Дополнительные технологии, такие как LINQ to XML и Parallel LINQ, великолепны. LINQ to Objects можно использовать практически везде.

LINQ to SQL и т. Д. Действительно хороши там, где они уместны, но их сложнее понять и требуют большего опыта. Они также применимы только в определенных областях вашего кода.

3 голосов
/ 07 ноября 2008

Моя любимая часть: их использование для упрощения написания юнит-тестов. Также IEnumerable цепочки побудили меня написать более свободный интерфейс в моем коде.

Минусы: лямбды и методы наращивания - мои молотки, а все проблемы - гвозди.

В целом: вдохнул новую жизнь в программирование на C # для меня.

1 голос
/ 07 ноября 2008

Я использовал LINQ в основном для работы над коллекцией объектов. LINQ прекрасно работает с коллекциями объектов, устраняя необходимость в функциях предикатов в большинстве случаев.

Я пытался использовать LINQ to SQL некоторое время назад, но нашел его недостаточно мощным и неуклюжим. В частности, я не мог заставить себя использовать конструктор классов базы данных SQL. Может быть, это дает intellisense для базы данных, но кому это нужно, когда у вас есть SQL?

Позвольте мне сказать вам, что, безусловно, было бы неплохо узнать больше о LINQ, поскольку количество приложений в будущем будет только увеличиваться.

1 голос
/ 07 ноября 2008

С ними связана проблема скрытия исключений из блоков try catch из-за отложенного выполнения.

например:

var l = new List<int>() {1, 2, 3};
try
{
    l.Select(x => x / 0);
}
catch
{
    // error
}

l.elementAt(0); // exception occurs here outside of the try catch

Что может быть сложно при первом запуске, особенно если отладчик укажет вам код внутри try-catch.

В остальном я нахожу их невероятно полезными и очень экономящими время.

0 голосов
/ 28 ноября 2008

Pro:

Con:

  • Как и любая новая технология, многие ее не понимают, но все еще используют

@ Джон Скит - еще один замечательный ответ: ты крадешь всякого грома: P. Я полностью согласен с тем, насколько сложно писать провайдеру, сейчас я в процессе! Вы знакомы с Бартом Де Сметом? У него есть много хороших примеров для этого.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...