Впервые, завеса тайны над C# 3.0 и проектом LINQ была приоткрыта примерно полтора года назад, когда создатели и идейные вдохновители этого проекта, Дон Бокс и Андрес Хэйлсберг, выступили на  PDC 2005 и поведали миру о том, что же это такое. С тех пор этот проект неоднократно обсуждался как в программерских форумах и блогах, так и на больших конференциях, в том числе и в России – Platforma, DevDays, WebDevCon, ect.… Однако время шло, релиза все не случалось, интерес угасал, и проект начал обрастать всяческими слухами, естественно, имеющими мало общего с действительностью, как приличным слухам и положено. В последнее же время, в силу ряда объективных причин – весна, полнолуние, неотвратимая близость релиза C# 3.0 LINQ, следующей версии Фреймворка и студии, разговоры о LINQ и C# 3.0 вспыхнули с новой силой, и со всей очевидностью стало ясно, что ясности в этом вопросе в народе нет. Осознав всю степень бедствия, я хочу попробовать написать несколько сообщений в блог, призванных устранить сумбур, восполнить пробел и навести прочий порядок в умах разработчиков, в меру моих скромных сил.… Впрочем, это сверхзадача, первоочередная же задача менее амбициозна - не запутать еще больше… Возможно из этого и статья какая-никакая получится...

Ну, приступим...

История LINQ-а начилась с того, что стояла задача, реализовать средства взаимодействия, между "обычными" языками программирования (читай ООП) и реляционными базами данных. В конце концов, сколько костылй на эту тему написано, а Майкрософт все никак…. Но в том-то и дело, что с одной стороны, написаны в основном костыли, весьма далекие от идеала, с другой – проблема несколько глубже. Ставший уже традиционным Oбъектно Oриентированый подход, не для всех задачь одинаково хорош,  причем, если вдуматься почему, то станет очевидным, что это «не для всех», не ограничивается реляционными базами, а относится в принципе к коллекциям. Иными словами, ООП отлично справляется с объектами, а вот с коллекциями объектов уже не так все радужно, таким образом, проблема более фундаментальна, чем принято считать. Коллекция ведь сущность довольно абстрактная и под нее попадает куча вещей, от строк в документе, и обычных массивов, до XML-узлов.

Понятное дело, что выразительности ООП достаточно, чтобы не ощущать этот недостаток в полный рост, и в принципе с ним мириться….  Но некий дискомфорт все равно присутствует, и особенно остро он ощущается при работе с реляционными источниками данных (там есть и другие фундаментальные проблемы, но они лежат совсем уж за пределами данной темы, однако все вместе это дает эффект перманентного раздражения седалищного нерва). И Майкрософт предпринял свою попытку вскрыть этот, прости-господи, нарыв, на первый взгляд довольно удачную.

И так, задача формулируется следующим образом: надо добавить в ООП язык средства работы с коллекциями. Где же их взять?  Пытливый ум, не может не заметить потрясающего успеха реляционных БД на этом фронте (реляционка ведь, по сути, просто набор коллекций). Оный успех, что для пытливого ума так же должно быть очевидно, объясняется потрясающей способностью оптимизаторов запросов, вылизанных до фантастического блеска, достать нужные данные наиболее оптимальным образом. Оптимизаторы же, в свою очередь, должны быть благодарны декларативному языку запросов, за то, что тот не суется не в свое дело. То есть языку, который лишь декларирует «что» ему надо получить, но не указывает «как» ему это надо сделать, «как» - это уже головная боль вышеупомянутого оптимизатора, в одной лапе у которого описание «что» из языка запросов, а в другой сакральные знания о том, «как именно» устроена система в данный момент и прочие хитрые метаданные. И тут, пытливый ум, со всей неизбежностью, приходит к выводу, что для достижения поставленной задачи, надо имеющийся ООП язык разбавить здоровой долей декларативности, корни которой лежат в функциональных языках.

Дальше, у ребят было несколько путей. Во-первых, можно было бы просто  оборудовать язык расширенной версией foreach для работы с коллекциями, и скрыть все потроха. На сколько мне известно так и поступят в следующей версии VB, и примерно так же это было реализовано в Comega (экспериментальный язык, послуживший прототипом для C# 3.0) . Во вторых, язык можно было расширить средствами метапрограммирования, которые позволили бы реализовать и искомый функционал с коллекциями и вообще все что угодно в виде библиотек. Если первый способ излишне консервативный, то второй, на мой взгляд, шибко радикальный. Но ребята пошли третим путем – они ввели в язык новый декларативный синтаксис, (совершенно случайно, он ужастно похож на SQL =), для работы с коллекциями, но не стали скрывать внутренности этого механизма - тот функционал, который позволяет этому языку запросов эффективно работать с разными источниками данных.  И эти новые возможности ценны сами по себе, вне зависимости от LINQ.

Собственно, дальнейшая серия постингов будет посвящена описанию этого нового функционала, пояснениям, ради чего он делался именно таким, какие цели ставились при его введении, что из этого получилось и как это можно использовать помимо Линка... То есть слово-то скорее всего получится замолвить не за LINQ, а за C# 3.0.. Ну тогда о Линке будет другая серия постов.. :)

По материалам http://blogs.gotdotnet.ru/personal/bezzus/