Помня о флэйме разгоревшемся по поводу того, что "LINQ to SQL оказался плохим O/R Mapper-ом" когда писали редакционную статью для журнала Технология Клиент-Сервер, мы решили обратиться к тему "что же такое LINQ to SQL". Вот что получилось. Надеюсь этот текст позволит многим правильно воспринять LINQ to SQL, а не искать в нем недостаки которых в нем нет.

Многие воспринимают LINQ to SQL как очередной O/R mapper, но реализованный Microsoft. Учитывая, что от Microsoft всегда ожидают намного большего, чем от более бедных компаний, и тем более от Open Source-разработчиков, у многих при первом знакомстве с LINQ to SQL наступает серьезное разочарование. Однако это разочарование вызвано неправильным пониманием сути используемого в LINQ to SQL подхода. Дело в том, что LINQ to SQL не является O/R mapper-ом. На самом деле LINQ – это абстрактное средство обработки списков, а отдельные разновидности LINQ, такие как LINQ to SQL или LINQ to XML, просто рассматривают некий источник данных как набор списков. Задача средств отображения, присутствующих, например, в LINQ to SQL, не в том, чтобы создать объектную модель, позволяющую скрыть детали БД и обеспечить эффективную обработку данных императивными средствами (в основном фильтрацию списков в циклах), а в том, чтобы ввести в программу некий набор классов, предназначенных для считывания в них данных из таблиц СУБД. При этом LINQ to SQL хотя и позволяет работать с такими классами императивными средствами, но заранее предупреждает, что это будет неэффективно и неудобно. Вместо этого LINQ to SQL предлагает использовать статически типизируемые, проверяемые во время компиляции, SQL-подобные запросы. Эти запросы транслируется в эффективный SQL, который выполняется СУБД. Результаты выполнения этих запросов преобразуются в списки типизированных объектов, которые удобно обрабатывать в таких объектно-ориентированных языках программирования, как VB и C#. Простой пример: предположим, у нас таблица покупателей (Customer), ссылающаяся на список заказов (у каждого покупателя может быть 0 или более заказов, Order), при этом в каждом заказе может быть 0 или более позиций (OrderDetail), и в наши задачи входит посчитать, сколько конкретному покупателю было продано единиц некоторого товара. Предположим, что идентификатор покупателя – ТКС, а идентификатор товара – БумагаА4. И классический O/R mapper, и LINQ to SQL при создании объектной модели для связи между таблицами генерируют соответствующие коллекции. Для нашего примера в классе Customer будет создана коллекция Orders, содержащая список объектов типа Order, а Order будет содержать коллекцию типа OrderDetails, содержащую, соответственно, список позиций заказов (объектов OrderDetail). При использовании традиционного O/R mapper-а было бы совершенно нормально написать код, который получает (с помощью некоторой хитрой функции Lookup) объект по его идентификатору, а дальше, с помощью двух вложенных циклов, пробегает по его коллекции, отбирая нужные элементы. Казалось бы, объем данных невелик (сколько может быть заказов у одного покупателя?), и перебор должен произойти практически мгновенно. Нужную позицию можно отфильтровать с помощью if. Однако ни O/R mapper, ни, тем более, СУБД не знают о наших замечательных намерениях и, если они не используют специальных техник, это приведет к тому, что для выборки каждого объекта будет выполнено отдельное обращение к БД. Конечно, хороший O/R mapper буквально напичкан специальными техниками, сглаживающими подобные неприятности (в частности, они могут выполнять опережающее чтение). Однако без тотального кэширования данных движком O/R mapper и, фактически, дублирования функций СУБД высокой производительности добиться не удастся. Поскольку серьезные БД в память априори не помещаются (тем более в объектном представлении), производительность всех без исключения O/R mapper-ов оставляет желать лучшего. Обратите внимание – это проблема системного характера, и решить ее принципиально, используя данный подход, невозможно. Как же быть? Более 20 лет назад производители СУБД (а именно IBM) решили эту проблему для своих продуктов. Решением был переход от навигационной системы к запросной с использованием языка запросов SQL. SQL в декларативной манере говорит СУБД, какие данные нужны клиенту, что потенциально позволяет СУБД построить эффективный план запроса и возвратить клиенту только требуемые данные. При этом экономятся как ресурсы сервера, так и трафик. Так вот, хотя LINQ to SQL и содержит набор возможностей, похожих на предоставляемые O/R mapper-ами вроде Hybernate, основным средством доступа к данным в нем является SQL-подобный язык запросов. LINQ же обеспечивает его безопасность, проверку ошибок на стадии компиляции, а поддержка Intellisense для запросов, встроенных в язык, появившаяся в VS 2008, существенно повышает производительность программирования. Именно так и нужно смотреть на LINQ, а что касается O/R mapper-а от Microsoft, он, по всей видимости, вскоре появится под названием LINQ to Entity, но, скорее всего, и эта реализация будет склонять программиста к использованию интегрированного языка запросов, а не императивного доступа к данным.

Здравствуйте, VladD2, Вы писали:

В тему, по поводу качества генерируемых запросов Outsmarted by LINQ-to-SQL

Здравствуйте, VladD2, Вы писали:

VD>На самом деле LINQ – это абстрактное средство обработки списков

Не списков, скорее неких произвольных контейнеров или оберток (собственно, требуется что бы аргумент был вида C<T>, где C и T — произвольные типы). Списочная семантика это уже особенности конкретного LINQ провайдера.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, VladD2, Вы писали:

VD>>На самом деле LINQ – это абстрактное средство обработки списков

AVK>Не списков, скорее неких произвольных контейнеров или оберток (собственно, требуется что бы аргумент был вида C<T>, где C и T — произвольные типы). Списочная семантика это уже особенности конкретного LINQ провайдера.

Что такое "неких произвольных контейнеров"? В математике есть понятие "список" и "множество". Вот понятие "список" и использовано. Ну, а C<T> это вообще не требование, а какая-то недоразумение. Под нее можно все что угдно загнать. LINQ даже расшифровывается как "интегрированные в язык ЗАПРОСЫ". Запросы можно делать только к множествам или спискам. В общем, не путай людей. Они сами запутаются.

Здравствуйте, VladD2, Вы писали:

VD>>>На самом деле LINQ – это абстрактное средство обработки списков
AVK>>Не списков, скорее неких произвольных контейнеров или оберток (собственно, требуется что бы аргумент был вида C<T>, где C и T — произвольные типы). Списочная семантика это уже особенности конкретного LINQ провайдера.
VD>Что такое "неких произвольных контейнеров"? В математике есть понятие "список" и "множество". Вот понятие "список" и использовано.

"Контейнер" — он и есть "множество".

VD>Ну, а C<T> это вообще не требование, а какая-то недоразумение. Под нее можно все что угдно загнать.

Так же как и контейнером можно назвать всё что пожелаешь.

VD>LINQ даже расшифровывается как "интегрированные в язык ЗАПРОСЫ". Запросы можно делать только к множествам или спискам.

Вот-вот, а ты только про списки и "запутал".

Здравствуйте, _FRED_, Вы писали:

_FR>"Контейнер" — он и есть "множество".

Ну, это проблемы вашего воображения. Для меня ведро не худший контейнер.

VD>>Ну, а C<T> это вообще не требование, а какая-то недоразумение. Под нее можно все что угдно загнать.

_FR>Так же как и контейнером можно назвать всё что пожелаешь.

Ну, вот чтобы не желали называть все что попало чем попало в математике и ввели понятие списка как упорядоченного множества.

VD>>LINQ даже расшифровывается как "интегрированные в язык ЗАПРОСЫ". Запросы можно делать только к множествам или спискам.

_FR>Вот-вот, а ты только про списки и "запутал".

Думаю, что все кто знаком с понятием списка все поняли. По крайней мере я, что-то вопросов не услышал.

Здравствуйте, VladD2, Вы писали:

Давно мучает вопрос по этому поводу. Если у меня есть более-менее серьёзный запрос к базе данных я делаю пользовательскую табличную функцию с параметрами и ложу её на сервер, где помещаю всё логику по выборке данных. От Linq мне тут надо только чтобы, он мне объект по результатам создал, но это и так давно умеют делать и без него. Потом мне гораздо проще менять SQL код, если чего не так, чем исходники. Вот и не понятно, чего это носятся все с этим linq. Хотя, конечно, если это не SQL провайдер, то может имеет смысл, но всё равно для XML, например, имхо часто вполне хватало XPath.

Здравствуйте, VladD2, Вы писали:

VD>Дело в том, что LINQ to SQL не является O/R mapper-ом. На самом деле LINQ – это абстрактное средство обработки списков, а отдельные разновидности LINQ, такие как LINQ to SQL или LINQ to XML, просто рассматривают некий источник данных как набор списков.

А в чем смысл такого средства? У меня есть функция, которая загружает списки из БД по коду объекта или по имени хп, чем этот LINQ лучше?

Здравствуйте, hell citizen, Вы писали:

HC>Здравствуйте, VladD2, Вы писали:

VD>>Дело в том, что LINQ to SQL не является O/R mapper-ом. На самом деле LINQ – это абстрактное средство обработки списков, а отдельные разновидности LINQ, такие как LINQ to SQL или LINQ to XML, просто рассматривают некий источник данных как набор списков.

HC>А в чем смысл такого средства? У меня есть функция, которая загружает списки из БД по коду объекта или по имени хп, чем этот LINQ лучше?

Это абстрактное средство обработки списков

LINQ к БД вообще никаким боком. Причем тут загрузка списков из БД по коду?

Здравствуйте, hugo, Вы писали:

H>LINQ к БД вообще никаким боком. Причем тут загрузка списков из БД по коду?

Речь идёт о LINQ to SQL.

Задача средств отображения, присутствующих, например, в LINQ to SQL, не в том, чтобы создать объектную модель, позволяющую скрыть детали БД и обеспечить эффективную обработку данных императивными средствами (в основном фильтрацию списков в циклах), а в том, чтобы ввести в программу некий набор классов, предназначенных для считывания в них данных из таблиц СУБД.

Такие средства есть, они хороши. Чем это новое средство лучше?

Здравствуйте, hell citizen, Вы писали:


HC>Речь идёт о LINQ to SQL.

Ну дык цитату ты закомментил в своем посте не про LINQ to SQL, а про смысл именно LINQ. Вот на это я и отвечал.

HC>

HC>Задача средств отображения, присутствующих, например, в LINQ to SQL, не в том, чтобы создать объектную модель, позволяющую скрыть детали БД и обеспечить эффективную обработку данных императивными средствами (в основном фильтрацию списков в циклах), а в том, чтобы ввести в программу некий набор классов, предназначенных для считывания в них данных из таблиц СУБД.

HC>Такие средства есть, они хороши. Чем это новое средство лучше?
А кто сказал, что оно лучше? LINQ to SQL — ИМХО вполне логичное применение технологии LINQ. Можно рассматривать, как замену DataSet'у.

Здравствуйте, trickyKid, Вы писали:

K>Давно мучает вопрос по этому поводу. Если у меня есть более-менее серьёзный запрос к базе данных я делаю пользовательскую табличную функцию с параметрами и ложу её на сервер, где помещаю всё логику по выборке данных. От Linq мне тут надо только чтобы, он мне объект по результатам создал, но это и так давно умеют делать и без него. Потом мне гораздо проще менять SQL код, если чего не так, чем исходники. Вот и не понятно, чего это носятся все с этим linq.

У тебя отдельный подход. Он конечно тоже имеет право на лево... тфу ты, жизнь . Однако у него есть свои достоинства и недостатки.
Мы можем получить от использования ЛИНК-а?
1. Поддержку интелисенса. Это повзоляет писать код быстрее и качественее. Так же это позволяет быстро и без проблем рефакторить код. Несмоненно тоже можно сделать для конкретного диалекта SQL, но ведь почему-то качественно это не сделано.
2. Проверку выражений на стадии компиляции. Это позволяет раньше выявлять общики, а чем раньше выявлена ошибка, тем проще ее устранить.
3. Поддержку разных источников данных. По мощьности ЛИНК-запросы, а темболее в купе с Шарпом, Васиком или темболее Немерле мягко говоря не уступают возможностям императивных расширений SQL-я вроде TSQL (MS) или PSQL (Oracle). Более того у ЛИНК-а отсуствуют некоторые ограничения вроде уровней рекурсии процедур и т.п. Так что для написания прикладной логики ЛИНК подходит даже лучше чем TSQL/PSQL. При этом код получается кросплатформным. Ну, или по крайней мере его будет намного проще сделать таковым.
4. Линк позволяет использовать в качестве источника данных не только БД, но и другие источники (коллекции объектов, ХМЛ, датасеты и т.п.). Это позволяет реализовывать неординарную логику используя один диалект языка запросов.
5. Линк позволяет осуществлять часть обработки вне СУБД. Это повзяоляет разгрузить СУБД и тем самым повысить производительностить и мастабируемость решений.

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

K>Хотя, конечно, если это не SQL провайдер, то может имеет смысл, но всё равно для XML, например, имхо часто вполне хватало XPath.

Согласен. Но XPath не встроен в язык вроде Шарпа. Надо понимать, что Линк-запросы — это не SQL. Это похожий на SQL язык. Но его база — это фунциональное программирование, т.е. декомпозиция запроса на вызов нескольких фуцний получающих критерии в качестве параметров (в виде фунций-лямбд). Таким образом это универсальный язык обработки данных. Наверно можно было бы облачить его в форму XPath, но выбран был именно SQL. Видимо потому, что он лучше ложится на фунциональную декомпозицию.

Приемущество именно Линка как раз и заключается в том, что запросы сливаются с основным языком. Производится сквозной контроль типов. Мы уже не может мполучить ошибку связанную с типом во время выполнения. Мы получим сообщение об ошибке еще при компиляции. Ну, и мы получим одинаковые сообщения для разных источников данных. Эта унификация доргого стоит. Особенно если думать о вопросах обучения новичков.

Здравствуйте, trickyKid, Вы писали:


K>Давно мучает вопрос по этому поводу. Если у меня есть более-менее серьёзный запрос к базе данных я делаю пользовательскую табличную функцию с параметрами и ложу её на сервер, где помещаю всё логику по выборке данных. От Linq мне тут надо только чтобы, он мне объект по результатам создал, но это и так давно умеют делать и без него. Потом мне гораздо проще менять SQL код, если чего не так, чем исходники. Вот и не понятно, чего это носятся все с этим linq. Хотя, конечно, если это не SQL провайдер, то может имеет смысл, но всё равно для XML, например, имхо часто вполне хватало XPath.

Ага, действительно, странно было бы написать всю бизнес-логику на T-SQL и использвать LINQ 2 SQL для получения результата на клиенте А повторное использование написанной таким образом БЛ меня лично повергает в большое уныние

Здравствуйте, VladD2, Вы писали:

VD>Приемущество именно Линка как раз и заключается в том, что запросы сливаются с основным языком. Производится сквозной контроль типов. Мы уже не может мполучить ошибку связанную с типом во время выполнения. Мы получим сообщение об ошибке еще при компиляции. Ну, и мы получим одинаковые сообщения для разных источников данных. Эта унификация доргого стоит.
Ага, сразу вспоминается PowerBuilder. Эта унификация очень дорого стоит.

Здравствуйте, hugo, Вы писали:

H>Здравствуйте, trickyKid, Вы писали:


K>>Давно мучает вопрос по этому поводу. Если у меня есть более-менее серьёзный запрос к базе данных я делаю пользовательскую табличную функцию с параметрами и ложу её на сервер, где помещаю всё логику по выборке данных. От Linq мне тут надо только чтобы, он мне объект по результатам создал, но это и так давно умеют делать и без него. Потом мне гораздо проще менять SQL код, если чего не так, чем исходники. Вот и не понятно, чего это носятся все с этим linq. Хотя, конечно, если это не SQL провайдер, то может имеет смысл, но всё равно для XML, например, имхо часто вполне хватало XPath.

H>Ага, действительно, странно было бы написать всю бизнес-логику на T-SQL и использвать LINQ 2 SQL для получения результата на клиенте А повторное использование написанной таким образом БЛ меня лично повергает в большое уныние

Какая-такая бизнес логика в SQL? Я говорю о отчётах, например, или выборка данных для "сложных" форм. Там чаще всего идёт толпа join и некоторое количество union с группировками и агрегациями. Тут, кстати, вижу плюс использования обычного SQL в том, что чтобы проверить работает ли запрос, мне не надо проект собирать весь. Как вы, кстати, собираетесь реализовывать бизнес логику на Linq 2 sql?

Хотя, конечно, понятно, что с linq 2 sql мне не надо на каждый мелкий запрос делать sql функцию и плодить к ней бизнес объект. Хотя, не помню, когда последний раз нужен был такой простой запрос, разультаты которого нельзя было бы вытянуть уже из загруженных бизнес объектов.

Здравствуйте, trickyKid, Вы писали:

K>>>Давно мучает вопрос по этому поводу. Если у меня есть более-менее серьёзный запрос к базе данных я делаю пользовательскую табличную функцию с параметрами и ложу её на сервер, где помещаю всё логику по выборке данных. <SKIPPED>

K>Какая-такая бизнес логика в SQL?

Ну вот та, что в предыдущем посте. Или это просто логикаб не бизнес?

K>Я говорю о отчётах, например, или выборка данных для "сложных" форм. Там чаще всего идёт толпа join и некоторое количество union с группировками и агрегациями. Тут, кстати, вижу плюс использования обычного SQL в том, что чтобы проверить работает ли запрос, мне не надо проект собирать весь.

Слово "отчеты" появились только сейчас. Я не придираюсь к словам, просто отчеты это немного другие "звери". Повторное использование кода в них не так важно. Естественно, некоторые задачи решаются лучше с помощью T-SQL.

K>Как вы, кстати, собираетесь реализовывать бизнес логику на Linq 2 sql?
Никак. Ее можно реализовать на *.NET языке, а LINQ 2 SQL является мостом между T-SQL с его таблицами и ООЯ с его объектами.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, trickyKid, Вы писали:

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

Было бы интересно посмотреть на нормальные решения, а не на примеры msdn или с блогов, где параметры hardcoded и 5 таблиц максимум используется.

K>>Хотя, конечно, если это не SQL провайдер, то может имеет смысл, но всё равно для XML, например, имхо часто вполне хватало XPath.

VD>Согласен. Но XPath не встроен в язык вроде Шарпа. Надо понимать, что Линк-запросы — это не SQL. Это похожий на SQL язык. Но его база — это фунциональное программирование, т.е. декомпозиция запроса на вызов нескольких фуцний получающих критерии в качестве параметров (в виде фунций-лямбд). Таким образом это универсальный язык обработки данных. Наверно можно было бы облачить его в форму XPath, но выбран был именно SQL. Видимо потому, что он лучше ложится на фунциональную декомпозицию.

С XML согласен, выглядит более удобным использовать human like запросы linq 2 xml чем время от времени вспоминать где какие слэши ставить в xpath.

Здравствуйте, hugo, Вы писали:

H>Здравствуйте, trickyKid, Вы писали:

K>>>>Давно мучает вопрос по этому поводу. Если у меня есть более-менее серьёзный запрос к базе данных я делаю пользовательскую табличную функцию с параметрами и ложу её на сервер, где помещаю всё логику по выборке данных. <SKIPPED>

K>>Какая-такая бизнес логика в SQL?

H>Ну вот та, что в предыдущем посте. Или это просто логикаб не бизнес?

Ну я имел ввиду максимум логику обработки параметров, а в остальном имел ввиду просто сложный запрос к базе. Linq ведь язык запросов? Сам не люблю когда появляются теже курсоры.

K>>Я говорю о отчётах, например, или выборка данных для "сложных" форм. Там чаще всего идёт толпа join и некоторое количество union с группировками и агрегациями. Тут, кстати, вижу плюс использования обычного SQL в том, что чтобы проверить работает ли запрос, мне не надо проект собирать весь.

H>Слово "отчеты" появились только сейчас. Я не придираюсь к словам, просто отчеты это немного другие "звери". Повторное использование кода в них не так важно. Естественно, некоторые задачи решаются лучше с помощью T-SQL.

Ну, не только отчёты... Если на форме торчит результат выборки из пару десятков таблиц, то имхо, тут тоже проще процедуру сделать...

K>>Как вы, кстати, собираетесь реализовывать бизнес логику на Linq 2 sql?
H>Никак. Ее можно реализовать на *.NET языке, а LINQ 2 SQL является мостом между T-SQL с его таблицами и ООЯ с его объектами.

Здесь будут множественные вызовы в базу и скорее всего транзакция на всё время работы этого кода, что тоже не есть хорошо. Хотя, конечно, приятнее писать логику(циклы и условия) на C# чем на TSQL.

Здравствуйте, hugo, Вы писали:

H>Здравствуйте, hell citizen, Вы писали:


HC>>Такие средства есть, они хороши. Чем это новое средство лучше?
H>А кто сказал, что оно лучше? LINQ to SQL — ИМХО вполне логичное применение технологии LINQ. Можно рассматривать, как замену DataSet'у.

Ну прям таки замена DataSet... Я что могу достать несколько связанных таблиц одним запросом? А версии записей разве он умеет отслеживать..?

Здравствуйте, trickyKid, Вы писали:


K>Ну, не только отчёты... Если на форме торчит результат выборки из пару десятков таблиц, то имхо, тут тоже проще процедуру сделать...

Почему же проще? Вполне красиво такой же запрос можно оформить и на LINQ'e. И вернет он объект/список объектов.

K>>>Как вы, кстати, собираетесь реализовывать бизнес логику на Linq 2 sql?
H>>Никак. Ее можно реализовать на *.NET языке, а LINQ 2 SQL является мостом между T-SQL с его таблицами и ООЯ с его объектами.

K>Здесь будут множественные вызовы в базу и скорее всего транзакция на всё время работы этого кода, что тоже не есть хорошо. Хотя, конечно, приятнее писать логику(циклы и условия) на C# чем на TSQL.

А если аналогичный запрос оформить в SP, то там транзакция не на все время работы скрипта будет? Не стоит также забывать обработку ошибок, которая на T-SQL выглядит совсем не так аккуратно, как, скажем, на C#, да и усилий для правильного написания кода обработки необходимо приложить значительно больше.