Строго типизированная работа с SQL-ем напрямую без LINQ - Архитектура программного обеспечения

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

G>>>>>Статическая проверка при компиляции для определенного заранее набора запросов.
AP>>>>И что?
G>>>И что что это по сути не дает возможностей декомпозиции, за счет которой Linq рулит.
AP>>Выше я уже писал, что декомпозиция присутствует.
G>Надо бы доказать.
Выше я приводил доказательство.

G>... Возможностей композиции я тут не вижу. ...
Как я могу тебе помочь это увидеть? Давай ты приведешь пример на linq, а я перепишу его на T4.

G>... а в базу уходит только выбор необходимых полей, с учетом derived table, подзапросов и тому подобной фигни.
Значение имеет только план запроса.

G>Ну давай сначала. Покажи код, который в post-compile time сможет проверить корректоность запроса, если он клеится из кусков строк в Runtime.
Как будет всё готово, я дам ссылку на codeplex. В первом сообщении я рассчитывал на опытных программистов, которые по краткому описанию в состоянии понять, что такой код можно написать. Ты видно не из их числа.

G>>>... Но это далеко не дотягивает до Linq.
AP>>Давай посмотрим, что до чего не дотягивает, приведи хотя бы схематично решение примера из первого поста.
G>Честно говоря лениво реверсить SQL. Уверен что в Linq можно сделать тоже самое, если не упрется в ограничения провайдера.
G>Вот сценарий для Linq:
G>

G>var query = GetQuery();
G>if(A)
G>{
G>    query = query.Where(...);
G>}
G>if(B)
G>{
G>    if(C)
G>    {
G>        query = SomeProcessQuery(query);
G>    }
G>    else
G>    {
G>        query = OtherProcessQuery(query);
G>    }
G>}
G>

Ага, переливать из пустого в порожний общие банальные фразы на протяжении десятка постов не лениво, а продемонстрировать код для примера из реального проекта вдруг лениво. Всё ясно. Пока не будет кода, засчитываем слив по этому примеру. Почитай комментарий IT. (Скрипт базы коммерческого проекта я, естественно, выложить не могу.)

G>Если использовать Linq то в конце процедуры у нас гарантированно корректный запрос.
G>Если клеим строки то гарантировать что-либо практически невозможно.
Как оказалось, можно для достаточно широкого множества use case-ов. Причем, замечательно то, что это множество полностью или почти полностью перекрывает потребности реальных проектов. Чего нельзя сказать о linq.

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

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

G>>>>>>Статическая проверка при компиляции для определенного заранее набора запросов.
AP>>>>>И что?
G>>>>И что что это по сути не дает возможностей декомпозиции, за счет которой Linq рулит.
AP>>>Выше я уже писал, что декомпозиция присутствует.
G>>Надо бы доказать.
AP>Выше я приводил доказательство.
На формальное доказательство это не тянет.

G>>... Возможностей композиции я тут не вижу. ...
AP>Как я могу тебе помочь это увидеть? Давай ты приведешь пример на linq, а я перепишу его на T4.
Да просто перепиши пример с ифами, который я приводил в посте. Меня не интересуют конкретные запросы, меня интересует подход.

G>>... а в базу уходит только выбор необходимых полей, с учетом derived table, подзапросов и тому подобной фигни.
AP>Значение имеет только план запроса.
Не-а, значение иммеет как запрос был получен. С помощью Linq можно построить оптимальный запрос под конкретную необходимость с минимальными усилиями. С текстом обычно приходится выписывать запрос полностью, а потом сопровождать его. Естественно в реальных проектах таких запросов становится слишком много и разработчики переходя к более универсальным запросам, жертвуя производительностью.

G>>Ну давай сначала. Покажи код, который в post-compile time сможет проверить корректоность запроса, если он клеится из кусков строк в Runtime.
AP>Как будет всё готово, я дам ссылку на codeplex. В первом сообщении я рассчитывал на опытных программистов, которые по краткому описанию в состоянии понять, что такой код можно написать. Ты видно не из их числа.
Мне хватает опыта заранее видеть тупиковые решения, особенно при наличии достойных альтернатив.

AP>Ага, переливать из пустого в порожний общие банальные фразы на протяжении десятка постов не лениво, а продемонстрировать код для примера из реального проекта вдруг лениво. Всё ясно. Пока не будет кода, засчитываем слив по этому примеру.
Какой ты быстрый

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

AP>Почитай комментарий IT.
Да это IT просто ленится. У меня вполне есть средство для решения обозначенной проблемы: http://gandjustas.blogspot.com/2010/06/expression-tree.html

G>>Если использовать Linq то в конце процедуры у нас гарантированно корректный запрос.
G>>Если клеим строки то гарантировать что-либо практически невозможно.
AP>Как оказалось, можно для достаточно широкого множества use case-ов. Причем, замечательно то, что это множество полностью или почти полностью перекрывает потребности реальных проектов. Чего нельзя сказать о linq.
А у меня с точностью наоборот.

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

G>Да просто перепиши пример с ифами, который я приводил в посте. Меня не интересуют конкретные запросы, меня интересует подход.

<# var query = GetQuery();
if(A)
{
    query = ToString(() => {#>
SELECT 
    *
FROM 
    (<#= query #>) T1
WHERE
    ...
<#    });
}
if(B)
{
    if(C)
    {
        query = SomeProcessQuery(query);
    }
    else
    {
        query = OtherProcessQuery(query);
    }
} #>

G>... У меня вполне есть средство для решения обозначенной проблемы: http://gandjustas.blogspot.com/2010/06/expression-tree.html
В интернетах это уже неоднократно встречалось. Это называется “закат солнца вручную” -- неоправданные девелоперские расходы.

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

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

G>>Да просто перепиши пример с ифами, который я приводил в посте. Меня не интересуют конкретные запросы, меня интересует подход.
AP>

AP><# var query = GetQuery();
AP>if(A)
AP>{
AP>    query = ToString(() => {#>
AP>SELECT 
AP>    *
AP>FROM 
AP>    (<#= query #>) T1
AP>WHERE
AP>    ...
AP><#    });
AP>}
AP>if(B)
AP>{
AP>    if(C)
AP>    {
AP>        query = SomeProcessQuery(query);
AP>    }
AP>    else
AP>    {
AP>        query = OtherProcessQuery(query);
AP>    }
AP>} #>
AP>

Так это же compile-time код, а условия A, B, C вычисляются в рантайме.

G>>... У меня вполне есть средство для решения обозначенной проблемы: http://gandjustas.blogspot.com/2010/06/expression-tree.html
AP>В интернетах это уже неоднократно встречалось. Это называется “закат солнца вручную” -- неоправданные девелоперские расходы.
Пару постов назад ты говорил что QueryObject позволяет в динамике строить запросы, а в linq работает компилятор. Я теперь привожу код, который позволяет в динамике строить ET, не генерируемые компилятором, при этом сохраняя проверки при компиляции, а ты говоришь что это “закат солнца вручную”. Ты уж определись тебе ехать надо (запросы писать) или шашечки (доказать кому-то что Linq хуже чего-то-там).

То что ты показываешь выглядит еще большими костылями, чем то что я тебе показываю.

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

G>Так это же compile-time код, а условия A, B, C вычисляются в рантайме.
A, B, C могут вычислять как хочешь, но всё сводится к двум значениям true/false (по каждой переменной), поэтому эти два значения можно перебрать в post-build и провалидировать запросы.

G>Пару постов назад ты говорил что QueryObject позволяет в динамике строить запросы, а в linq работает компилятор. Я теперь привожу код, который позволяет в динамике строить ET, не генерируемые компилятором, при этом сохраняя проверки при компиляции, а ты говоришь что это “закат солнца вручную”. Ты уж определись тебе ехать надо (запросы писать) или шашечки (доказать кому-то что Linq хуже чего-то-там).
Определяться не зачем, в моих словах и так всё последовательно, противоречий нет. Известный факт, что классический QueryObject для нетривиальных запросов это “закат солнца вручную”, так же как и формирование вручную ET для linq. Ну не дизайнился linq для такой динамики, вот ответ Anders Hejlsberg-а. А если бы такая динамика дизайнелась, то продукт был бы сильно другим.
То что вы делаете похоже на Emit вместо обычного кода на C#-е, для прикладных бизнес задач это накладно.

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

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

G>>Так это же compile-time код, а условия A, B, C вычисляются в рантайме.
AP>A, B, C могут вычислять как хочешь, но всё сводится к двум значениям true/false (по каждой переменной), поэтому эти два значения можно перебрать в post-build и провалидировать запросы.
Вот об этом я и говорил. Ты пытаешься автоматизировать предварительное создание всех запросов. Это значит что при изменении логики (добавлении if) надо будет еще и генератор править.

G>>Пару постов назад ты говорил что QueryObject позволяет в динамике строить запросы, а в linq работает компилятор. Я теперь привожу код, который позволяет в динамике строить ET, не генерируемые компилятором, при этом сохраняя проверки при компиляции, а ты говоришь что это “закат солнца вручную”. Ты уж определись тебе ехать надо (запросы писать) или шашечки (доказать кому-то что Linq хуже чего-то-там).
AP>Определяться не зачем, в моих словах и так всё последовательно, противоречий нет. Известный факт, что классический QueryObject для нетривиальных запросов это “закат солнца вручную”, так же как и формирование вручную ET для linq.
Для нетривиильных запросов написание текстового SQL еще хуже, чем применение Linq. Утверждать что "чтототам вручную" глупо, потому что других вариантов нету.

AP>Ну не дизайнился linq для такой динамики, вот ответ Anders Hejlsberg-а. А если бы такая динамика дизайнелась, то продукт был бы сильно другим.
Да мне пофигу, я сам допилю где не хватает. ET вполне успешно генерируются в рантайме.

AP>То что вы делаете похоже на Emit вместо обычного кода на C#-е, для прикладных бизнес задач это накладно.
Я делаю emit, который мне на 90% дает компилятор. А ты пытаешься сразу писать в IL

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

G>... Это значит что при изменении логики (добавлении if) надо будет еще и генератор править.
Нет, для кастомной логики генератор править не надо, в этом и фишка. Ты так и не понял сути, а флудишь уже второй десяток постов.

G>Для нетривиильных запросов написание текстового SQL еще хуже, чем применение Linq. Утверждать что "чтототам вручную" глупо, потому что других вариантов нету.
В том то и фишка, что теперь есть.

AP>>... А ты пытаешься сразу писать в IL

SQL отнюдь не IL.

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

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

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

G>>Для нетривиильных запросов написание текстового SQL еще хуже, чем применение Linq. Утверждать что "чтототам вручную" глупо, потому что других вариантов нету.
AP>В том то и фишка, что теперь есть.
Где? Покажи.

AP>>>... А ты пытаешься сразу писать в IL

AP>SQL отнюдь не IL.
Ну и Linq — тоже не emit.
Пустая риторика.

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

G>Вот именно, я не понял как ты собираешься решать проблему декомпозиции-композиции запросов. Ты показываешь только самые простые случаи, и то они уже дают оверхед.
Ну тк помоги мне понять того, что ты не понимаешь. В моем подходе “проблема декомпозиции-композиции запросов” имеет тривиальный смысл. В моем подходе “запрос” это строка не больше не меньше. “Проблема декомпозиции-композиции запросов” это что проблема склеивания строк? Ее решают T4, Razor, StringBuilder.

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

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

G>>Вот именно, я не понял как ты собираешься решать проблему декомпозиции-композиции запросов. Ты показываешь только самые простые случаи, и то они уже дают оверхед.
AP>Ну тк помоги мне понять того, что ты не понимаешь. В моем подходе “проблема декомпозиции-композиции запросов” имеет тривиальный смысл. В моем подходе “запрос” это строка не больше не меньше. “Проблема декомпозиции-композиции запросов” это что проблема склеивания строк? Ее решают T4, Razor, StringBuilder.

Именно, запросы надо клеить в рантайме. T4 и Razor делают это в compile-time, а запрос в StringBuilder ты не проверишь на корректность при компиляции.
Ты это понимаешь?

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

G>>Именно, запросы надо клеить в рантайме. T4 и Razor делают это в compile-time
У T4 есть режим Run-time text generation http://msdn.microsoft.com/en-us/library/bb126445.aspx

G>>... а запрос в StringBuilder ты не проверишь на корректность при компиляции.

static void Main(string arg)
{
    ExecuteQuery(GetQueryText(bool.Parse(arg)))
}

static void ExecuteQuery(string queryText)
{
...
}

static string GetQueryText(bool condition)
{
    if (condition)
    {
        return "SELECT A FROM T1";
    }
    else
    {
        return "SELECT A FROM T2";
    }
}

В post-buil дергаем GetQueryText(true), GetQueryText(false).

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

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

G>>>Именно, запросы надо клеить в рантайме. T4 и Razor делают это в compile-time
AP>У T4 есть режим Run-time text generation http://msdn.microsoft.com/en-us/library/bb126445.aspx
Неважно

G>>>... а запрос в StringBuilder ты не проверишь на корректность при компиляции.
AP>

AP>static void Main(string arg)
AP>{
AP>    ExecuteQuery(GetQueryText(bool.Parse(arg)))
AP>}

AP>static void ExecuteQuery(string queryText)
AP>{
AP>...
AP>}

AP>static string GetQueryText(bool condition)
AP>{
AP>    if (condition)
AP>    {
AP>        return "SELECT A FROM T1";
AP>    }
AP>    else
AP>    {
AP>        return "SELECT A FROM T2";
AP>    }
AP>}
AP>

AP>В post-buil дергаем GetQueryText(true), GetQueryText(false).
Опять не вижу композиции, есть выбор только одного из набора заранее определенных запросов.
Это естественно приводит к тому что их надо согласованно править. И никто тебе не подскажет что ты не во всех местах поправил.

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

G>>>>... а запрос в StringBuilder ты не проверишь на корректность при компиляции.
AP>>

AP>>static void Main(string arg)
AP>>{
AP>>    ExecuteQuery(GetQueryText(bool.Parse(arg)))
AP>>}

AP>>static void ExecuteQuery(string queryText)
AP>>{
AP>>...
AP>>}

AP>>static string GetQueryText(bool condition)
AP>>{
AP>>    if (condition)
AP>>    {
AP>>        return "SELECT A FROM T1";
AP>>    }
AP>>    else
AP>>    {
AP>>        return "SELECT A FROM T2";
AP>>    }
AP>>}
AP>>

AP>>В post-buil дергаем GetQueryText(true), GetQueryText(false).
G>Опять не вижу композиции, есть выбор только одного из набора заранее определенных запросов.
G>Это естественно приводит к тому что их надо согласованно править. И никто тебе не подскажет что ты не во всех местах поправил.
Не отвлекайся. Ты тут должен был увидеть, что, если динамичность запросов зависит от “bool condition”, то валидность таких запросов можно проверить в post-build. И не важно как клеится запрос, может и через StringBuilder. Это ты видишь?

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

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

G>>>>>... а запрос в StringBuilder ты не проверишь на корректность при компиляции.
AP>>>

AP>>>static void Main(string arg)
AP>>>{
AP>>>    ExecuteQuery(GetQueryText(bool.Parse(arg)))
AP>>>}

AP>>>static void ExecuteQuery(string queryText)
AP>>>{
AP>>>...
AP>>>}

AP>>>static string GetQueryText(bool condition)
AP>>>{
AP>>>    if (condition)
AP>>>    {
AP>>>        return "SELECT A FROM T1";
AP>>>    }
AP>>>    else
AP>>>    {
AP>>>        return "SELECT A FROM T2";
AP>>>    }
AP>>>}
AP>>>

AP>>>В post-buil дергаем GetQueryText(true), GetQueryText(false).
G>>Опять не вижу композиции, есть выбор только одного из набора заранее определенных запросов.
G>>Это естественно приводит к тому что их надо согласованно править. И никто тебе не подскажет что ты не во всех местах поправил.
AP>Не отвлекайся. Ты тут должен был увидеть, что, если динамичность запросов зависит от “bool condition”, то валидность таких запросов можно проверить в post-build. И не важно как клеится запрос, может и через StringBuilder. Это ты видишь?
Не вижу, ты же не показал склейку через StringBuilder а рантайме, ты показал выбор из заранее определенного набора строк.

Ты вообще подумай почему был придуман паттерн QueryObject, если, как ты утверждаешь, можно таки клеить строки и иметь гарантии при компиляции.

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

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

static void Main(string arg)
{
    ExecuteQuery(GetQueryText(bool.Parse(arg)))
}

static void ExecuteQuery(string queryText)
{
...
}

static string GetQueryText(bool condition)
{
    return new StringBuilder().AppendFormat("SELECT A FROM {0}", condition ? "T1" : "T2").ToString();
}

Теперь видишь?

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

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

G>>Не вижу, ты же не показал склейку через StringBuilder а рантайме, ты показал выбор из заранее определенного набора строк.
AP>

AP>static void Main(string arg)
AP>{
AP>    ExecuteQuery(GetQueryText(bool.Parse(arg)))
AP>}

AP>static void ExecuteQuery(string queryText)
AP>{
AP>...
AP>}

AP>static string GetQueryText(bool condition)
AP>{
AP>    return new StringBuilder().AppendFormat("SELECT A FROM {0}", condition ? "T1" : "T2").ToString();
AP>}
AP>

AP>Теперь видишь?

Отлично, а теперь как ты сможешь гарантировать что-либо при компиляции? Особенно если учесть что "T1" и "T2" также могут быть склеены в рантайме, и проекция "A" может меняться.
Напиши такой статический верификатор.

	От:	Alexander Polyakov
	Дата:	13.11.10 18:26
	Оценка:

	От:	Alexander Polyakov
	Дата:	13.11.10 20:08
	Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	14.11.10 00:47
Оценка:

	От:	Alexander Polyakov
	Дата:	14.11.10 12:57
	Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	14.11.10 13:04
Оценка:

	От:	Аноним
	Дата:	15.11.10 11:43
	Оценка:

От:	IT	linq2db.com
Дата:	15.11.10 14:37
Оценка: