Является ли LINQ to Everything хорошей абстракцией?

Question

Существует множество новых поставщиков LINQ. Это действительно удивительное и элегантное сочетание лямбда-выражений, анонимных типов и обобщений с некоторым синтаксическим сахаром сверху, чтобы облегчить чтение. Теперь все LINQed от SQL до веб-сервисов, таких как Amazon до потоковых данных датчика до параллельная обработка . Кажется, что кто-то создает IQueryable <T> для всего, но эти источники данных могут иметь радикально отличающиеся характеристики производительности, задержки, доступности и надежности.

Это дает мне небольшую паузу, потому что LINQ делает эти детали производительности прозрачными для разработчика. Является ли LINQ надежной абстракцией общего назначения или инструментом RAD, или и тем, и другим?

Answer 1

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

Это не что иное, как элемент синтаксиса вокруг обычных интерфейсов и методов - здесь нет «волшебства», и LINQ-to-что-то действительно (IMO) должно рассматриваться как любой другой сторонний API - вам нужно понимать стоимость преимущества его использования, как и любой другой технологии.

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

Answer 2

Полагаю - нет.

LINQ - это просто удобный синтаксис, но не обычный инструмент RAD. В больших проектах со сложной логикой я заметил, что разработчики делают больше ошибок в LINQ, чем в тех же инструкциях, которые они могут делать, если пишут одно и то же в .NET 2.0. Код создается быстрее, он меньше, но труднее найти ошибки. Иногда с первого взгляда не очевидно, в какой момент запрашиваемая коллекция превращается из IQueryable в IEnumerable ... Я бы сказал, что для LINQ требуются более опытные и дисциплинированные разработчики.

Кроме того, SQL-подобный синтаксис подходит для функционального программирования, но это шаг в сторону от объектно-ориентированного мышления. Иногда, когда вы видите 2 очень похожих запроса LINQ, они выглядят как код для копирования и вставки, но не всегда возможен какой-либо рефакторинг (или это возможно только путем потери некоторой производительности).

Я слышал, что MS не собирается дальше развивать LINQ to SQL и будет уделять больше внимания сущностям. Команда ADO.NET отказывается от LINQ to SQL? Разве это не является для нас сигналом того, что LINQ не является панацеей для всех?

Если вы планируете создать соединитель для « что-то », вы можете создать его без LINQ и, если хотите, предоставить LINQ в качестве дополнительной необязательной оболочки вокруг него, например, LINQ to Entities. Таким образом, ваши клиенты будут решать, использовать ли LINQ или нет, в зависимости от их потребностей, требуемой производительности и т. Д.

p.s. .NET 4.0 придет с динамикой, и я ожидаю, что все также начнут использовать их в качестве LINQ ... без учета соображений, из-за которых могут пострадать простота, качество и производительность кода.

Answer 3

Я вижу это как , похожее на модель нескольких механизмов хранения в СУБД, принимающую общий (-ish) язык SQL, в своем дизайне ... но с дополнительным преимуществом интеграции в семантика языка приложения. Конечно это хорошо!

Я не использовал его так много, но он выглядит разумным и ясным, когда производительность и уровни абстракции не в состоянии оказать негативное влияние на процесс разработки (и верю, что стандарты и модели не будут сильно меняться).

Это просто интерфейс и реализация, которая может соответствовать вашим потребностям , как и все интерфейсы, абстракции, библиотеки и реализации, подходит ли она? ... это все те же ответы .