IT> Если точная структура не известна, то нужно создавать запрос в виде некоего SQL AST, а затем с помощью SQL провайдеров создавать SQL под конкретную СУБД. IT> Соответствующие средства есть в BLToolkit, в нём Linq-провайдер как раз организован по схеме Linq-provider -> SqlQuery -> SqlProvider.
2) Нельзя ли обойтись без второго провайдера, дополнительного к .Net Data Provider (типа MySqlDataProvider)?
Прочитал, как создать провайдера программно: http://www.bltoolkit.net/Doc.LinqConfig.ashx
может ли быть так, что .Net предоставляет средства для формирования запросов в рамках .Net Data Provider?
Ведь как-то же они создают SQL запросы из Linq...
Неясно, зачем для моей задачи нужен BLToolkit,
до конца неясно, как сделать без него.
Re[8]: Динамическое формирование SQL-запросов из C# кода
IT> Для Linq модель данных должна быть известна во время компиляции
не для Linq, а для Linq-провайдера to SQL, который применяется по-умолчанию.
Можно ли реализовать другой провайдер,
основная задача которого — абстрагировать прикладного программиста от синтаксиса SQL?
Этот новый провайдер должен уметь (можно магическим прошитым в коде способом) обращаться
к нужному виду .Net Data Provider-а.
основная задача .Net Data Provider-а — абстрагировать от особенностей синтаксиса БД.
В новом Linq-провайдере в качестве реализации использовать не конкретные типы, а коллекции,
чтобы не генерировать для них классы на ходу.
А дополнительную метаинформацию, пусть получает где-нибудь еще, из базы, например.
При этом не получится статической проверки типов,
но зато две другие нужные цели будут достигнуты...
(Цели — 1) это независимый от БД код запросов 2) это трансляция к нужному типу БД)
Re[8]: Динамическое формирование SQL-запросов из C# кода
С помощью этого создаётся Expression Tree, в пронципе, тоже что-то типа AST. Далее, всего лишь навсего, это AST нужно будет разобрать и сформировать по нему SQL. У меня на решение этой задачи ушёл год
AS>2) Нельзя ли обойтись без второго провайдера, дополнительного к .Net Data Provider (типа MySqlDataProvider)?
Аналога SqlProvider в .NET нет. Может быть можно как-то вскрыть потроха EF, но про официальный и задокументированный от MS мне ничего не известно.
AS>может ли быть так, что .Net предоставляет средства для формирования запросов в рамках .Net Data Provider? AS>Ведь как-то же они создают SQL запросы из Linq...
Они пишут Linq-провайдер, который парсит Expression Tree и формируют по нему SQL.
AS>Неясно, зачем для моей задачи нужен BLToolkit,
BLToolkit предоставляет такой же как и другие Linq провайдер со своими достоинствами и преимуществами. Разница лишь в том, что обычная схема у Linq-провайдеров, видимая снаружи — это Expression Tree (ET) -> SQL, а у BLToolkit — это ET -> SqlQuery -> SqlProvider -> SQL. Другими словами, дизайн потрохов всего хозяйства заточен на публичное использование и расширение.
Если твоя модель данных заранее определена, то Linq тебе вполне подойдёт. ET можно без проблем формировать программно без помощи компилятора. Большинство провайдеров такое ET схавают и выдадут тебе необходимый результат. BLToolkit здесь может быть интересен лишь по причине наличия DML и более широкого спектра поддерживаемых БД.
Если модель данных заранее не известна, то тебе нужна схема SqlQuery (Sql Builder) -> SqlProvider -> SQL. BLToolkit её предоставляет. Может быть лишь потребуется отполировать API, т.к. хотя и с оглядкой на независимое использование, он всё же писался под Linq.
AS>до конца неясно, как сделать без него.
Написать свой велосипед.
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: Динамическое формирование SQL-запросов из C# кода
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>не для Linq, а для Linq-провайдера to SQL, который применяется по-умолчанию. AS>Можно ли реализовать другой провайдер, AS>основная задача которого — абстрагировать прикладного программиста от синтаксиса SQL? AS>Этот новый провайдер должен уметь (можно магическим прошитым в коде способом) обращаться AS>к нужному виду .Net Data Provider-а.
Зачем магия? Указал в конфиге Connection String и обратились куда нужно.
AS>основная задача .Net Data Provider-а — абстрагировать от особенностей синтаксиса БД.
SqlProvider рулит.
AS>В новом Linq-провайдере в качестве реализации использовать не конкретные типы, а коллекции, AS>чтобы не генерировать для них классы на ходу. AS>А дополнительную метаинформацию, пусть получает где-нибудь еще, из базы, например.
Да без проблем. Sql Builder + Sql Provider.
AS>При этом не получится статической проверки типов, AS>но зато две другие нужные цели будут достигнуты... AS>(Цели — 1) это независимый от БД код запросов 2) это трансляция к нужному типу БД)
Круто!
Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: Динамическое формирование SQL-запросов из C# кода
IT> AST нужно будет разобрать и сформировать по нему SQL. IT> дизайн потрохов всего хозяйства заточен на публичное использование и расширение. IT> У меня на решение этой задачи ушёл год
IT> Написать свой велосипед.
Не вижу необходимости
1) решать задачу формирования SQL по ET, потому что она уже решена в промышленном решении от Microsoft,
2) использовать стороннюю библиотеку, так как мне не надо поддержки дополнительных БД и расширять что-либо внутри
IT> Если твоя модель данных заранее определена, то Linq тебе вполне подойдёт.
я уже говорил, что "определена" — это непонятное мне слово.
значит ли оно что надо генерировать конкретные классы при помощи Reflection.Emit
или можно без этого обойтись (и как обойтись, если можно)
IT> ET можно без проблем формировать программно без помощи компилятора.
Вот это именно то, что мне наверное надо.
Неясно следующее:
— как сделать (и можно ли), чтобы не приходилось генерировать типы при помощи Reflection.Emit
для того, чтобы заработал механизм MS
— как формировать ET так, чтобы их понимал стандартный Linq-провайдер
(туториал где-нибудь есть по переводу запросов SQL в ET ?)
Если нам не помогут, то мы тоже никого не пощадим.
