Должен ли я беспокоиться о пути обновления для LINQ (язык запросов)

Question

Я начинаю использовать LINQ как истинный язык запросов в коде, чтобы улучшить читаемость. До недавнего времени я боялся прикоснуться к LINQ из-за того, что команда LINQ to SQL перешла под команду Entity Framework (пытаясь игнорировать этот разговор здесь) - будет ли LINQ язык запросов безопасным вариантом на будущее (как и все в этом быстром движущаяся индустрия)?

Answer 1

Стоит проводить различие между «LINQ» и «конкретным поставщиком LINQ». Я думаю, можно с уверенностью сказать, что сам LINQ здесь, чтобы остаться - и это феноменально полезно для обработки коллекции в процессе через LINQ to Objects.

Что касается того, какой провайдер LINQ "выиграет" (если таковой имеется) - это сложнее сделать ставку.

Я бы определенно изучил бы основы самой LINQ, хотя LINQ to XML также является прекрасным XML API.

Answer 2

Как сказал Джон, очень важно различать поставщиков LINQ. Например

• LINQ к объектам: это основано на IEnumerable и настолько укоренилось в BCL, что мне очень тяжело, что оно куда-то движется
• LINQ to SQL: я использую это не так часто, как LINQ, но я знаю, что у него хорошие последователи, и людям это нравится.

Предостережение: я работал над LINQ, поэтому здесь я довольно предвзят.

Что действительно здорово в LINQ, то, что, я думаю, мы действительно поняли, заключается в том, что каждый может написать поставщика LINQ. Все, что нужно, - это несколько привязываемых методов с правильным именем, и вдруг у вас появляется синтаксис запроса.

var query = from it in someCollection select it.SomeProperty;

Я могу написать это утверждение, не используя какие-либо рамки 3.5. У меня есть мой собственный поставщик LINQ , который работает против инфраструктуры 2.0 и совместим с синтаксисом запросов, используемым в компиляторе.

Лично я больше склоняюсь к синтаксису лямбда / метода расширения, но полученный код на самом деле ничем не отличается.