Статья:
Linq with BLToolkit

Автор(ы): Игорь Ткачёв
Дата: 15.02.2010

Авторы:
Игорь Ткачёв

Аннотация:
Сегодня Linq уже не нуждается в особом представлении и рекомендациях. Эта технология с каждым днём получает всё больше распространение и всё сильнее завоёвывает признание разработчиков. BLToolkit так же не остался в стороне и предлагает свой Linq-provider для доступа к базам данным. Целью данного документа как раз является предоставление информации о поддержки Linq в BLToolkit.

Здравствуйте, Игорь Ткачёв, Вы писали:

ИТ>Аннотация:
ИТ>Сегодня Linq уже не нуждается в особом представлении и рекомендациях. Эта технология с каждым днём получает всё больше распространение и всё сильнее завоёвывает признание разработчиков. BLToolkit так же не остался в стороне и предлагает свой Linq-provider для доступа к базам данным. Целью данного документа как раз является предоставление информации о поддержки Linq в BLToolkit.
Спасибо, про CompiledQuery не знал, хорошая штука.

А для batch update/delete операций можно делать некий UpdatePreview(), чтобы до выполнения увидеть SQL?
Если нет SubmitChanges, то в какие моменты происходят все обновления в базе?
Реально ли BLToolkit прикрутить к LinqPad?

Еще интересует завершенность LINQ в BLToolkit. На ormbattle.net видно, что какие-то тесты не проходятся еще, хотя данные наверное устарели. Т.е. интересует вопрос, все ли доделано и если не доделано, то что именно и когда примерно планируется.

Здравствуйте, Димчанский, Вы писали:

Д>Если нет SubmitChanges, то в какие моменты происходят все обновления в базе?

В момент вызова методов Insert/Update/Delete

Здравствуйте, Димчанский, Вы писали:

Д>Еще интересует завершенность LINQ в BLToolkit. На ormbattle.net видно, что какие-то тесты не проходятся еще, хотя данные наверное устарели. Т.е. интересует вопрос, все ли доделано и если не доделано, то что именно и когда примерно планируется.

Базовый функционал доделан. А вообще развивать можно почти до бесконечности.

Здравствуйте, Игорь Ткачёв.

Я правильно понял, что для связей типа многие-ко-многим (через промежуточную таблицу с двумя полями-внешними ключами) мы должны явно описывать эту таблицу в коде в виде отдельного класса? Или можно как-то скрыть существование этой таблицы куда-нибудь подальше (просто указав имя промежуточной таблицы где-нибудь в атрибуте или еще как) и использовать в ассоциациях в коде коллекции из самих конечных, а не таких вот промежуточных/переходных сущностей (чтобы получилась более "чистая" модель классов)?

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

AVK>Базовый функционал доделан. А вообще развивать можно почти до бесконечности.

Я просто смотрю, что здесь Linq вроде как должен быть в версии 3.2, но она сейчас в разработке еще. Поэтому интересует, когда выйдет некая стабильная 3.2 с базовым функционалом. Т.е. не таскать же каждый день latest.

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

AVK>В момент вызова методов Insert/Update/Delete

А как-то средставми BLT можно обновлять только то (в том числе отдельные поля), что реально изменилось?

Здравствуйте, Игорь Ткачёв, Вы писали:

то, о чм так долго просили большевики, наконец-то случилось

Здравствуйте, Димчанский, Вы писали:

AVK>>В момент вызова методов Insert/Update/Delete

Д>А как-то средставми BLT можно обновлять только то (в том числе отдельные поля), что реально изменилось?

Можно. Но это не имеет отношения к LINQ.

Здравствуйте, Димчанский, Вы писали:

Д>Поэтому интересует, когда выйдет некая стабильная 3.2 с базовым функционалом.

Скоро.

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

H>Спасибо, про CompiledQuery не знал, хорошая штука.

Хорошая, но не очень удобная.

Здравствуйте, Димчанский, Вы писали:

Д>А для batch update/delete операций можно делать некий UpdatePreview(), чтобы до выполнения увидеть SQL?

Batch операции пока сделаны вообще мимо поддержки Linq, через старый интерефейс SqlQuery. Но SQL посмотреть можно после выполнения операции в DbManager.LastQuery. Но надо учитывать, что пакетов может быть много и увидеть можно только последний.

Д>Если нет SubmitChanges, то в какие моменты происходят все обновления в базе?

Обновления происходят явно вызовами DML команд Insert/Update/Delete.

Д>Реально ли BLToolkit прикрутить к LinqPad?

Здравствуйте, Димчанский, Вы писали:

Д>Еще интересует завершенность LINQ в BLToolkit. На ormbattle.net видно, что какие-то тесты не проходятся еще, хотя данные наверное устарели. Т.е. интересует вопрос, все ли доделано и если не доделано, то что именно и когда примерно планируется.

Последние результаты тестов нужно смотреть здесь. Сами тесты с описанием результатов прохода здесь. В основном не проходят тесты, связанные с загрузкой списков подчинённых записей. Никаких принципиальных причин для того, что не сделать эту фичу нет, кроме того, что надо решить как лучше это сделать. Т.к. вариантов хоть и много, но идеального ни одного.

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

О>Я правильно понял, что для связей типа многие-ко-многим (через промежуточную таблицу с двумя полями-внешними ключами) мы должны явно описывать эту таблицу в коде в виде отдельного класса? Или можно как-то скрыть существование этой таблицы куда-нибудь подальше (просто указав имя промежуточной таблицы где-нибудь в атрибуте или еще как) и использовать в ассоциациях в коде коллекции из самих конечных, а не таких вот промежуточных/переходных сущностей (чтобы получилась более "чистая" модель классов)?

А как такое описание и такой запрос будет выглядеть в коде?

Здравствуйте, Димчанский, Вы писали:

Д>Я просто смотрю, что здесь Linq вроде как должен быть в версии 3.2, но она сейчас в разработке еще. Поэтому интересует, когда выйдет некая стабильная 3.2 с базовым функционалом. Т.е. не таскать же каждый день latest.

К релизу мы готовы. Сегодня/завтра будет зафиксирована версия. Скорее всего та, которая сейчас находится в репозитории.

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

Д>>А как-то средставми BLT можно обновлять только то (в том числе отдельные поля), что реально изменилось?
AVK>Можно. Но это не имеет отношения к LINQ.

Я имел ввиду, что если на обычном Linq2Sql я напишу нечто вроде:

var prod = new Product { ID=1000, Description ="Description", Discontinued = false, LastSale = DateTime.Now };
Products.InsertOnSubmit(prod);

SubmitChanges();

prod.Discontinued = true; // здесь я не знаю, какие изменения произошли и в каких полях

SubmitChanges();

то получу такие SQL запросы:

DECLARE @p0 Int SET @p0 = 1000
DECLARE @p1 VarChar(11) SET @p1 = 'Description'
DECLARE @p2 Bit SET @p2 = 0
DECLARE @p3 DateTime SET @p3 = '2010-02-25 18:11:06.789'

INSERT INTO [Product]([ID], [Description], [Discontinued], [LastSale])
VALUES (@p0, @p1, @p2, @p3)
GO

DECLARE @p0 Int SET @p0 = 1000
DECLARE @p1 Bit SET @p1 = 1

UPDATE [Product]
SET [Discontinued] = @p1
WHERE [ID] = @p0

Причем, если бы я вообще никакого реального изменения не сделал (хотя присвоения и были, но тех же самых значений),
то никакого апдейта реально в базе бы не произошло.
В L2S я получаю такие оптимизации из коробки.
Как я понял BLT больше похож на SQL с синтаксисом и соответствующими фичами C#.

Но если так, то как бы можно было сделать финты оптимизации изменений как в L2S? Т.е. получается, нужно создать некий механизм по отслеживания изменений в объекте и затем динамически сгенерировать запрос на обновление.
Как бы это можно было красиво сделать с использованием BLT?

Здравствуйте, Димчанский, Вы писали:

Д>Как бы это можно было красиво сделать с использованием BLT?

Это всё элементы Entity Service (в частности это — Change Tracking), которых в BLT нет. Пока.

Здравствуйте, Димчанский, Вы писали:

Д>Как бы это можно было красиво сделать с использованием BLT?
Никак. Читать раздел "Идеология и модель программирования". BLToolkit тем и ценнен, что не занимается такой ерундой, как отслеживание изменений.