Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Повторяю вопрос — тебе хотя бы раз такое понадобилось? Мне вот, за 18 лет стажа, большая часть которого связана с БД, не понадобилось ни разу. Но если вдруг понадобится — тоже не проблема. Придется только поправить неймспейсы и перекомпилировать, чтобы ET заменилось на лямбды.

Была SQL CE с Linq to SQL, а понадобилась хранить данные в ESENT. Ко второй бд провайдеры только экспериментальные.

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

G>Какая от этого польза? Вред мы уже видели, а польза где?

Декомпозиция. Следование принципу "разделяй и властвуй".

G>У тебя получается более сложный код. Потому что потребитель твоего репозитария вынужден формировать класс DataFetch, а внутри репозитария надо этот DataFetch разбирать и собирать Linq запросы. Так еще и статической проверки DataFetch нету.
G>Не веришь? так попробуй реализовать сценарии, которые я приводил:
G>1) Показывать посты по дате добавления
G>2) Показывать посты по количеству оценок за день (самые популярные)
G>3) Показывать посты по комментов за день (самые обсуждаемые)

G>Сравни с объемом кода, скоростью разработки и затратами на поддержку без репозитариев

Наследник DataFetch всегда предельно конкретный, там не 100500 фильтров и метод выборки занимает полэкрана. И этот код легко читать и поддерживать.

G>Я могу легко создать десятки интерфейсов-аспектов и комбинаторов к ним, а ты все поместишь в EntityFetch ? Прости, но такое решение будет неюзабельным совершенно. Да и какая гарантия в твоем коде что сущность вообще поддерживает нужный аспект? Никакой. Поэтому получаем больше ошибок и больше кода.

Проблема в том, что тебе не нужны "десятки интерфейсов-аспектов" в твоём приложении. Ты тратишь впустую время на универсальные решения.

G>Ты комменты прочитай, нет необходимости в этом методе, достаточно написать T:class

Нет вообще никакой необходимости в этом коде, он лишний начиная с интерфейса. Код похож на подход "теперь я знаю лямбды" и соответственно всё можно описать с помощью лямбд.

G>Ты выше показываешь как раз "универсальный велосипед" со своим EntityFetch.

Он конкретный и простой, это просто набор параметров.

G>А проекция? как ты её задавать будешь? А нетривиальные фильтры?

А зачем они мне вообще? Я делаю конкретное приложение и все необходимые фильтры я уже описал, мне не требуется универсальный велосипед.

G>Вот в этом и проблема. Значит запросы будут гораздо менее эффективными от применения репозитариев. А польза в чем?

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

G>Я вообще не понимаю где будет упрощение, если у тебя внутри репозитариев такой же Linq, но параметры ты передаешь через дополнительный (!) класс EntityFetch, с которым ошибиться на порядок проще. Кода больше, ошибок больше, где "простой как доска"?

Кода меньше и он не тычит деталями реализации мне в лицо. "Эй, смотри! У нас есть IQueryable! Представь какие возможности открываются!"

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ничего не понял. А как же репозиторий и абстрагируемость?

Ну раз они тебе за 18 лет ни разу не понадобились...

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

К>>Почему начинаете издалека? Лучше сразу к делу — зачем нужно ООП.

D>ООП я использую практически постоянно, вопросов "зачем" не возникает

Тут два варианта:
1) Вы не используете реляционные СУБД.
2) Вы преобразуете модель "ручками".

Здравствуйте, Крякозавр, Вы писали:

К>Тут два варианта:
К>1) Вы не используете реляционные СУБД.
Использую. Реляции, т.е., зависимости, тоже использую. Не, мне далеко до топовых оперденей, но какие-то простые вещи делаю.

К>2) Вы преобразуете модель "ручками".
У меня когда-то был удобный инструмент — Sybase PowerDesigner. Сейчас меня жаба душит его покупать (потому как БД пишу для личных/хобби нужд), поэтому — да, "ручками", Есть файл sql, создающий базу, есть набор sql, эту базу меняющих.

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

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

G>>Какая от этого польза? Вред мы уже видели, а польза где?

V>Декомпозиция. Следование принципу "разделяй и властвуй".

Декомпозиция прекрасно делается без репозиториев и кучи классов.

G>>У тебя получается более сложный код. Потому что потребитель твоего репозитария вынужден формировать класс DataFetch, а внутри репозитария надо этот DataFetch разбирать и собирать Linq запросы. Так еще и статической проверки DataFetch нету.
G>>Не веришь? так попробуй реализовать сценарии, которые я приводил:
G>>1) Показывать посты по дате добавления
G>>2) Показывать посты по количеству оценок за день (самые популярные)
G>>3) Показывать посты по комментов за день (самые обсуждаемые)

G>>Сравни с объемом кода, скоростью разработки и затратами на поддержку без репозитариев

V>Наследник DataFetch всегда предельно конкретный, там не 100500 фильтров и метод выборки занимает полэкрана. И этот код легко читать и поддерживать.

Покажи код.

G>>Я могу легко создать десятки интерфейсов-аспектов и комбинаторов к ним, а ты все поместишь в EntityFetch ? Прости, но такое решение будет неюзабельным совершенно. Да и какая гарантия в твоем коде что сущность вообще поддерживает нужный аспект? Никакой. Поэтому получаем больше ошибок и больше кода.

V>Проблема в том, что тебе не нужны "десятки интерфейсов-аспектов" в твоём приложении. Ты тратишь впустую время на универсальные решения.
Если мне не нужны, то не трачу.

G>>Ты комменты прочитай, нет необходимости в этом методе, достаточно написать T:class
V>Нет вообще никакой необходимости в этом коде, он лишний начиная с интерфейса. Код похож на подход "теперь я знаю лямбды" и соответственно всё можно описать с помощью лямбд.
С чего ты взял что нет необходимости? Как раз наоборот. Много сущностей имеют одинаковые аспекты — владение, видимость, права доступа, url slug, наличие имени итп.
Тебе придется все эти аспекты запихнуть в один EntityFetch и у тебя не будет проверки компилятором, в случае если сущность не поддерживает аспект. "Предельно конкретные наследники" EntityFetch у тебя не получатся, потому что одна сущность будет поддерживать аспекты владения и прав доступа, а вторая — наличие имени и url slug.
Интерфейсы комбинаторы выполняют тоже функцию, что и EntityFetch, только надежнее и меньше кода. Странно что ты утверждаешь что они лишние, тогда EntityFetch вообще не в тему, а его еще и руками разбирать надо *facepalm*


G>>Ты выше показываешь как раз "универсальный велосипед" со своим EntityFetch.
V>Он конкретный и простой, это просто набор параметров.
Ага, не проверяемый компилятором, который надо вручную разобрать. И который со временем распухнет для неральных размеров. Даже если ты сделаешь по одному EntityFetch для каждой сущности, то проблему это не решат из-за повторяющихся аспектов у тебя появится копипаста. А если по одному EntityFetch на запрос, то это банально хуже обычных методов, потом что в методах компилятор проверяет наличие параметров.

G>>А проекция? как ты её задавать будешь? А нетривиальные фильтры?
V>А зачем они мне вообще? Я делаю конкретное приложение и все необходимые фильтры я уже описал, мне не требуется универсальный велосипед.

Без проекций будет тормозить. Любой способ работы с базой без проекций не жизнеспособен на практике.
Как ты будешь проекции описывать со своим DataFetch? И какой тип ты при этом будешь возвращать из методов репозитариев?

G>>Вот в этом и проблема. Значит запросы будут гораздо менее эффективными от применения репозитариев. А польза в чем?

V>С чего такая уверенность?
Рецепт эффективного запроса — предикат с высокой селективностью и проекция. Ты пока не показал ни того, ни другого.

V>Запросы находятся в одном месте, их легко отлаживать и при необходимости изменить.
Расскажи нам кк легко отлаживать запросы, которые в одном месте? помоему для отладки запросов надо в SQL Profiler смотреть, а не в репозитарий.
Кроме того, если у тебя запросы на 50% повторяются, то ты не будешь применять декомпозицию linq, а будешь копипастить? Если будешь декомпозировать, то у тебя запросы перестанут быть в одном месте.

Попробуй напиши код репозиториев для сценариев, которые я уже раз десять озвучил. Сам все увидишь.

V>Никаких IQueryable наружу не торчит и не надо постоянно глядеть как и где оно используется.
А с чего ты взял что надо куда-то глядеть? Какие вообще проблемы могут быть?

G>>Я вообще не понимаю где будет упрощение, если у тебя внутри репозитариев такой же Linq, но параметры ты передаешь через дополнительный (!) класс EntityFetch, с которым ошибиться на порядок проще. Кода больше, ошибок больше, где "простой как доска"?

V>Кода меньше и он не тычит деталями реализации мне в лицо. "Эй, смотри! У нас есть IQueryable! Представь какие возможности открываются!"
Если ты повторяешь что кода меньше его меньше не становится. Ты уже придумал лишние классы, которые надо создавать и разбирать их в методах репозитария, с чего меньше кода станет? Наоборот, его больше получается. И с каждым твоим постом потенциальный объем кода растет, а надежность и производительность падает. Про детали реализации не понял какая проблема.

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

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

Почему?

G>В линке нет готовых средств для обхода деревьев

В линке вообще нет готовых средств. Средства предоставляют конкретные провайдеры.

G>Ты куда-то в сторону ушел.



G>3) Все пляски с Expression Trees и linq-comprehensions сделаны только для трансляции запросов в SQL. В других языках есть query comprehensions, которые гораздо лаконичнее с такой же выразительной силой.

Это Мейер говорил? Ты точно в этом уверен? Потому что когда я с ним разговаривал, он говорил совсем иное.

G>У тебя есть возражения?

Не не не. Ты давай расскажи, где это Мейер рассказывал что выразительность у линка меньше, чем у SQL.

G>Во-первых внутри ET можно написать любое выражение языка, например создание несериализуемых объектов.

Это мелочь. Проблема не в этом. А вот то что легко написать GroupBy, который придется транслировать в килограмм запрросов — вот это уже конкретная проблема выразительности SQL.

G> Во-вторых linq работает с последовательностям

Это — в корне неверно. Последовательности для линка — лишь частный случай. И даже в рамках последовательностей — у линка свойство элемента последовательности легко и логично может быть последовательностью. А вот у SQL с этим совсем не все так просто.

G>, а SQL с множествами, разница в семантике делает многие linq выражения бессмысленными в SQL. Но оба эих факта никаким образом не связаны с выразительной силой.

Это ты так думаешь. А на самом деле это прямое следствие большей выразительности линка.

G>Фактически выразительная сила — возможность получить больше результатов выражений, используя меньше кода.

Угу. И уже одна возможность не писать в линке большую часть джойнов вполне себе наглядно демонстрирует, какой из языков выразительнее. А если к тому добавить убогость и громоздкость CTE по сравнению с простейшими способами декомпозиции в линке, то я вообще не понимаю как можно не видеть очевидного.
Скажи, кстати, а зачем приделали возможность писать хранимки на дотнете? Это тоже от очень большой выразительности SQL?

G> Если мы рассматриваем работу с данными, то Linq, увы, в не дотягивает до SQL.

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

НС>>Ничего не понял. А как же репозиторий и абстрагируемость?

V>Ну раз они тебе за 18 лет ни разу не понадобились...

То есть ответить на вопрос ты не можешь. ЧТД.

Здравствуйте, Ночной Смотрящий, Вы писали:

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

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

НС>Почему?

Потому что надо внутри select генерировать order by и ROWS clause. Это будет аццкий монстр в виде linq.

G>>В линке нет готовых средств для обхода деревьев
НС>В линке вообще нет готовых средств. Средства предоставляют конкретные провайдеры.
После этого ты утверждаешь что linq выразительнее?


G>>3) Все пляски с Expression Trees и linq-comprehensions сделаны только для трансляции запросов в SQL. В других языках есть query comprehensions, которые гораздо лаконичнее с такой же выразительной силой.
НС>Это Мейер говорил? Ты точно в этом уверен? Потому что когда я с ним разговаривал, он говорил совсем иное.
Нет, это по факту. С момента появления linq прошло более 5 лет, но до сих пор кроме трансляции в SQL достойных применений у ET практически нет.

G>>У тебя есть возражения?
НС>Не не не. Ты давай расскажи, где это Мейер рассказывал что выразительность у линка меньше, чем у SQL.
Я не говорил что Мейер это рассказывал.

G>>Во-первых внутри ET можно написать любое выражение языка, например создание несериализуемых объектов.
НС>Это мелочь. Проблема не в этом. А вот то что легко написать GroupBy, который придется транслировать в килограмм запрросов — вот это уже конкретная проблема выразительности SQL.
И ниже ты пишешь что linq не работает с последовательностями.

G>> Во-вторых linq работает с последовательностям
НС>Это — в корне неверно. Последовательности для линка — лишь частный случай. И даже в рамках последовательностей — у линка свойство элемента последовательности легко и логично может быть последовательностью. А вот у SQL с этим совсем не все так просто.
Мы сейчас говорим об IQueryable<T>, который наследует IEnumerable<T>, который, внезнапно, обозначает последовательность. Так вот GroupBy, возвращает специальный вид последовательности — IGrouping, а SQL не знает о таком, у него на выходе всегда реляция (таблица). Но это совершенно не значит, что SQL обладает меньшей мощностью, он умудряется без специальных типов последовательностей реализовывать то же самое. Только для этого используются как раз ranking fucntions, которые ни один провайдер не поддерживает.
Повторяю еще раз чтобы ты понял — в Linq придуман специальный тип последовательности, когда SQL обходится несколькими дополнительными функциями.


G>>, а SQL с множествами, разница в семантике делает многие linq выражения бессмысленными в SQL. Но оба эих факта никаким образом не связаны с выразительной силой.
НС>Это ты так думаешь. А на самом деле это прямое следствие большей выразительности линка.
То есть обосновать ты не можешь.

G>>Фактически выразительная сила — возможность получить больше результатов выражений, используя меньше кода.

НС>Угу. И уже одна возможность не писать в линке большую часть джойнов вполне себе наглядно демонстрирует, какой из языков выразительнее.
О да, неявное вписывание left join по ключу это конечно выразительной силы добавляет. Это наверное единственное преимущество выразительности linq перед sql.

НС>А если к тому добавить убогость и громоздкость CTE по сравнению с простейшими способами декомпозиции в линке, то я вообще не понимаю как можно не видеть очевидного.
Тем не менее CTE позволят делать рекурсивные запросы, а linq нет. И даже хорошего синтакиса для рекурсивных запросов в linq нету.

НС>Скажи, кстати, а зачем приделали возможность писать хранимки на дотнете? Это тоже от очень большой выразительности SQL?
Нет, это от неумения пользоваться SQL. Кстати крайне не рекомендуется делать CLR-хранимки для выборки данных

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

НС>>Почему?
G>Потому что надо внутри select генерировать order by и ROWS clause.

Это не проблема.

G> Это будет аццкий монстр в виде linq.

Не думаю.

НС>>В линке вообще нет готовых средств. Средства предоставляют конкретные провайдеры.
G>После этого ты утверждаешь что linq выразительнее?

Да.

НС>>Это Мейер говорил? Ты точно в этом уверен? Потому что когда я с ним разговаривал, он говорил совсем иное.
G>Нет, это по факту.



G> С момента появления linq прошло более 5 лет, но до сих пор кроме трансляции в SQL достойных применений у ET практически нет.

Тебе так кажется. Тот же МСовский клиент к odata. У полнотекстовых движков и поисковиков провайдеры бывают. У NoSQL, опять же, без этого обычно не обходится. Просто задача общения с РСУБД настолько огромная, что затмевает все остальное.

НС>>Не не не. Ты давай расскажи, где это Мейер рассказывал что выразительность у линка меньше, чем у SQL.
G>Я не говорил что Мейер это рассказывал.

G>>> Linq создавался как раз чтобы не сильно отставать по выразительности от SQL.
НС>>Это ты сам придумал?
G>Нет, об этом Мейер говорил.

НС>>Это мелочь. Проблема не в этом. А вот то что легко написать GroupBy, который придется транслировать в килограмм запрросов — вот это уже конкретная проблема выразительности SQL.
G>И ниже ты пишешь что linq не работает с последовательностями.

Прочти внимательнее что я пишу. Вот ключевая фраза: "Последовательности для линка — лишь частный случай."

G>Мы сейчас говорим об IQueryable<T>

С чего ты взял?

G>Так вот GroupBy, возвращает специальный вид последовательности — IGrouping,

IGrouping это не просто последовательность, это дерево.

G> а SQL не знает о таком, у него на выходе всегда реляция (таблица)

Ну вот, ты и сам все по поводу выразительности SQL понимаешь.

G>. Но это совершенно не значит, что SQL обладает меньшей мощностью

Именно это это и значит. Средства SQL не позволяют удобно работать с деревьями, даже совсем простыми.

G>, он умудряется без специальных типов последовательностей реализовывать то же самое

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

G>, когда SQL обходится несколькими дополнительными функциями.

Ну давай, продемонстрируй выразительность SQL на простеньком запросике:

db
  .Messages
  .Select(
    m =>
      new
      {
        m.Id,
        Rates = m.Rates.Where(r => r.MessageId = m.Id && r.Type == RateType.Positive),
        Replies = db.Messages.Where(sm => sm.ParentId = m.Id)
      })

НС>>Это ты так думаешь. А на самом деле это прямое следствие большей выразительности линка.
G>То есть обосновать ты не можешь.

Я уже обосновал.

НС>>Угу. И уже одна возможность не писать в линке большую часть джойнов вполне себе наглядно демонстрирует, какой из языков выразительнее.
G>О да, неявное вписывание left join по ключу это конечно выразительной силы добавляет.

Почему обязательно left join? И да, добавляет. Некоторые запросы сокращает в разы. Если это не выразительность, то я даже и не знаю что ты за нее принимаешь.

G> Это наверное единственное преимущество выразительности linq перед sql.

Не единственное. Но ты согласен что линк выразительнее хотя бы в этом?

НС>>А если к тому добавить убогость и громоздкость CTE по сравнению с простейшими способами декомпозиции в линке, то я вообще не понимаю как можно не видеть очевидного.
G>Тем не менее CTE позволят делать рекурсивные запросы, а linq нет.

Потому что линку это ненужно.

НС>>Скажи, кстати, а зачем приделали возможность писать хранимки на дотнете? Это тоже от очень большой выразительности SQL?
G>Нет, это от неумения пользоваться SQL.

С тобой все понятно.

Здравствуйте, Ночной Смотрящий, Вы писали:


НС>>>Не не не. Ты давай расскажи, где это Мейер рассказывал что выразительность у линка меньше, чем у SQL.
G>>Я не говорил что Мейер это рассказывал.

НС>

G>>>> Linq создавался как раз чтобы не сильно отставать по выразительности от SQL.
НС>>>Это ты сам придумал?
G>>Нет, об этом Мейер говорил.

Ты в демагогии подкован.

То что выразительность linq меньше SQL — я сказал, а то что linq делали похожим на SQL — Мейер. Ищи на Channel в записях 2007-2009 года. Там же Мейер рассказывал что он делал на хаскеле. Сложить 1 и 1 и получить 2 ты и сам сможешь.

Здравствуйте, Ночной Смотрящий, Вы писали:

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


G>> С момента появления linq прошло более 5 лет, но до сих пор кроме трансляции в SQL достойных применений у ET практически нет.

НС>Тебе так кажется. Тот же МСовский клиент к odata. У полнотекстовых движков и поисковиков провайдеры бывают. У NoSQL, опять же, без этого обычно не обходится. Просто задача общения с РСУБД настолько огромная, что затмевает все остальное.

Что мне кажется? Odata использует как раз Iqueryable, который в 99,9% случаев отдается ORMом.

G>>Мы сейчас говорим об IQueryable<T>
НС>С чего ты взял?
Мы говорили про ORM, это ты начал расширять тему до полной бесполезности. ORM это IQueryablr<T>

G>>Так вот GroupBy, возвращает специальный вид последовательности — IGrouping,
НС>IGrouping это не просто последовательность, это дерево.
В каком месте оно дерево? Это IEnumerable+Key. Для дерева нужно как минимум иметь список дочерних элементов или ссылку на родителя.

G>> а SQL не знает о таком, у него на выходе всегда реляция (таблица)
НС>Ну вот, ты и сам все по поводу выразительности SQL понимаешь.
Да, а ты не понимаешь. SQL может больше выборок описать используя меньше понятий.

G>>. Но это совершенно не значит, что SQL обладает меньшей мощностью
НС>Именно это это и значит. Средства SQL не позволяют удобно работать с деревьями, даже совсем простыми.
Что ты понимаешь под "удобно работать с деревьями" ? hierarchyid это не удобно?

G>>, он умудряется без специальных типов последовательностей реализовывать то же самое
НС>В том то и проблема, что не умудряется. Только совсем примитивные случаи, когда вложенная последовательность сворачивается в небольшой набор агрегатов. Если же дерево свернуть не удается, то все, приплыли, выразительность SQL закончилась.
Ты пытаешся свое незнание показать? hierarchyid не пробовал? Работа с деревьями в SQL пройдена уже столько раз, что даже лень перечислять все способы.
А то что в отсуствие навигационного доступа и кучи других понятий SQL умудряется делать более сложные выборки, конечно не говорит о его выразительности.

G>>, когда SQL обходится несколькими дополнительными функциями.

НС>Ну давай, продемонстрируй выразительность SQL на простеньком запросике:
НС>

НС>db
НС>  .Messages
НС>  .Select(
НС>    m =>
НС>      new
НС>      {
НС>        m.Id,
НС>        Rates = m.Rates.Where(r => r.MessageId = m.Id && r.Type == RateType.Positive),
НС>        Replies = db.Messages.Where(sm => sm.ParentId = m.Id)
НС>      })
НС>

Запрос получает все сообщения с всеми положительными оценками и ответами. то есть тянешь всю таблицу ответов и все положительные оценки.

Эквивалентный SQL:

select r.* from Rates r where r.Type = 1
select r.* from Replies r

И все. message даже трогать не надо, так как m.Id есть в обоих таблицах.
Потом DataReader в dictionary мапишь и все.


НС>>>Это ты так думаешь. А на самом деле это прямое следствие большей выразительности линка.
G>>То есть обосновать ты не можешь.
НС>Я уже обосновал.
"Это ты так думаешь." (с)

НС>>>Угу. И уже одна возможность не писать в линке большую часть джойнов вполне себе наглядно демонстрирует, какой из языков выразительнее.
G>>О да, неявное вписывание left join по ключу это конечно выразительной силы добавляет.
НС>Почему обязательно left join? И да, добавляет. Некоторые запросы сокращает в разы. Если это не выразительность, то я даже и не знаю что ты за нее принимаешь.
В редких случаях inner join. Сокращает в разы по сравнению с чем? Обычно SQL код более компактный, только очень неудобный для программиста.

G>> Это наверное единственное преимущество выразительности linq перед sql.
НС>Не единственное. Но ты согласен что линк выразительнее хотя бы в этом?
Только в этом. Но я уже приводил список чего linq не умеет.

НС>>>А если к тому добавить убогость и громоздкость CTE по сравнению с простейшими способами декомпозиции в линке, то я вообще не понимаю как можно не видеть очевидного.
G>>Тем не менее CTE позволят делать рекурсивные запросы, а linq нет.
НС>Потому что линку это ненужно.
Демагогия 80 уровня.
Вижу что аргументы у тебя так и не появились.

Я думаю на этом можно закончить.

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

G>Что мне кажется? Odata использует как раз Iqueryable, который в 99,9% случаев отдается ORMом.

Это неважно откуда он отдается. Главное — это другое применение. И обрабатывается ЕТ там по другому.

НС>>С чего ты взял?
G>Мы говорили про ORM, это ты начал расширять тему до полной бесполезности. ORM это IQueryablr<T>

Мы говорили про выразительность. И это просто еще один пример того, что выразительность линка неизверимо выше чем у SQL.

G>>>Так вот GroupBy, возвращает специальный вид последовательности — IGrouping,
НС>>IGrouping это не просто последовательность, это дерево.
G>В каком месте оно дерево? Это IEnumerable+Key.

Это IEnumerable<IEnumerable>. SQL такое не умеет.

G> Для дерева нужно как минимум иметь список дочерних элементов или ссылку на родителя.

IGrouping и есть список дочерних элементов. И в линке GroupBy может быть вложенным, с чем в SQL вообще полный швах.

НС>>Именно это это и значит. Средства SQL не позволяют удобно работать с деревьями, даже совсем простыми.
G>Что ты понимаешь под "удобно работать с деревьями" ?

То и понимаю. Неудобно и многословно, с привлечением мозголомсной рекурсии.

G> hierarchyid это не удобно?

Нет.

G>Ты пытаешся свое незнание показать?

Нет, это ты, как обычно, считаешь других за дураков.

G>Запрос получает все сообщения с всеми положительными оценками и ответами. то есть тянешь всю таблицу ответов и все положительные оценки.

Это пример. Неужели не дошло.

G>Эквивалентный SQL:
G>

G>select r.* from Rates r where r.Type = 1
G>select r.* from Replies r 
G>

G>И все.

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

G> message даже трогать не надо, так как m.Id есть в обоих таблицах.

Ты же понимаешь что это пример? Если нет — ну допиши туда еще m.Subject.

G>Потом DataReader в dictionary мапишь и все.

Ишь какой хитрый. Мы ж про выразительность, не так ли? Так вот будь добр меппинг тоже выразить на SQL.

НС>>Почему обязательно left join? И да, добавляет. Некоторые запросы сокращает в разы. Если это не выразительность, то я даже и не знаю что ты за нее принимаешь.
G>В редких случаях inner join.

Почему в редких? Обычно inner намного чаще присутствует, чем outer. А если у EF с этим проблемы — это вовсе не из-за линка, а из-за кривости EF.

G> Сокращает в разы по сравнению с чем?

С явным расписыванием джойнов.

G> Обычно SQL код более компактный, только очень неудобный для программиста.

Ну давай, распиши на сиквеле компактно, сравним. Можно без джойнов.

db
    .Messages
    .Select(m => new {
      m.Subject,
      m.Account.Nick,
      m.Forum.Name,
      rateCount = m.Rates.Count(),
      rateSum = m.Rates.Sum(r => r.Value),
      replyCount = m.Replies.Count(),
      lastReplyDate = m.Replies.Max(rl => rl.CreatedOn)})

НС>>Не единственное. Но ты согласен что линк выразительнее хотя бы в этом?
G>Только в этом.

Не только

G> Но я уже приводил список чего linq не умеет.

Ты привел список того, чего не умеют конкретные провайдеры, не более того.

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

G>Ты в демагогии подкован.

G>То что выразительность linq меньше SQL — я сказал, а то что linq делали похожим на SQL — Мейер. Ищи на Channel в записях 2007-2009 года. Там же Мейер рассказывал что он делал на хаскеле. Сложить 1 и 1 и получить 2 ты и сам сможешь.
Тут в целом хорошо видно, кто в демагогии подкован )
"похожим" и "не сильно отставать по выразительности" — это не одно и тоже. И я тоже не помню, чтобы Мейер жаловался на выразительность linq.

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

V>а понадобилась хранить данные в ESENT. Ко второй бд провайдеры только экспериментальные.

Что за зверь? Для него есть .NET Data Provider? Там вообще что под низом? SQL? Если да, то можно сделать для этой штуки Linq провайдер.

Здравствуйте, IT, Вы писали:
IT>Что за зверь? Для него есть .NET Data Provider?
https://managedesent.codeplex.com/wikipage?title=ManagedEsentDocumentation

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

IT>>Что за зверь? Для него есть .NET Data Provider?
QL>https://managedesent.codeplex.com/wikipage?title=ManagedEsentDocumentation

Т.е. к этой штуке для начала нужно .NET Data Provider написать?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Vladek, Вы писали:

НС>>>Ничего не понял. А как же репозиторий и абстрагируемость?

V>>Ну раз они тебе за 18 лет ни разу не понадобились...

НС>То есть ответить на вопрос ты не можешь. ЧТД.

извиняюсь, что встрал.
меня интересует, в случае, когда репозиторий отдаёт IQueryable, то на чьей совести управление подключением к бд? получается, контроллер должен заниматься этим?

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

E>извиняюсь, что встрал.
E>меня интересует, в случае, когда репозиторий отдаёт IQueryable, то на чьей совести управление подключением к бд? получается, контроллер должен заниматься этим?

Что ты понимаешь под управлением? Инициировать открытие соединения или начало транзакции, разумеется, должен контроллер. Больше просто некому. А вот непосредственно конфигурированием подключения и созданием экземпляра коннекшена должна заниматься инфраструктура.

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

Улыбался с каждой строчки этого твоего поста.
Могу ответить попунктно на все твои непонимания.

Опыт общения с тобой показывает, что ты можешь переваривать не более одного вопроса в единицу поста. Поэтому сначала пройдемся по WPF, Студии и Калькулятору.


V>>>>А я говорил, что ты не понимаешь нифига. Visual Studio вышла до выхода WinRT. Более того, она должна работать даже на тех версиях виндов, где WinRT не поддерживается. Более того, запуск студии в 5-15 секунд никого не волнует. Это же утилитное приложение. Вот если бы виндовый калькулятор запускался 5-15 секунд, то никто бы его не использовал. Вот почему в коробочных продуктах фактически нет WPF.

G>>>Действительно не понимаю как это связано. Похоже что связь у тебя в голове только существует.

V>>Я же сразу сказал — не понимаешь нифига. Не понимаешь, почему студия написана на WPF, а не на WinRT. Не понимаешь, почему виндовый калькулятор на WPF не написан, хотя (я уверен) будет переписан на winRT (или уже полно аналогов с аналогичным временем запуска, как у старого).

G>Я не понимаю к чему ты это пишешь. Калькулятор в W8 кстати есть в виде app на JS.

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