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

Question

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

Answer 1

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

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

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

Answer 2

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

• ПРИВЯЗКА к объектам:Это основано на IEnumerable<T> и настолько укоренилось в BCL, что мне очень сложно добиться чего-либо подобного
• ССЫЛКА на SQL:Я использую это далеко не так часто, как LINQ, но я знаю, что у него хорошие подписчики, и людям, похоже, это нравится.

Предостережение:Я работал над LINQ, так что здесь я довольно предвзят.

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

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

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

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