Comments 27
Зачем вы так про GraphQL?
Graphql это язык запросов к вашему приложению, он никак не зависит от IQueryable или чего-то ещё — вы сами выбираете (=реализуете) какую фильтрацию поддерживаете.
То есть, он не течёт*, там строгая схема, которую вы сами обязались реализовать.
В HotChocolate (реализация gql для дотнет) 11 версии ребята вообще отказались от IQueryable.
(*может течь, если уровень вложенности select'a становится больше какого-то, задаваемого разработчиком, уровня)
(*может течь, если уровень вложенности select'a становится больше какого-то, задаваемого разработчиком, уровня)
Я имел в виду именно такие варианты. Речь не о IQueryable
как таковом, а о том, чтобы выдавать наружу язык запросов. Наверняка существуют API, для которых Graphql — самое то. Но для многих других rest-like вполне достаточно.
Но в остальном вы правы, GraphQL не влечет за собой рассмотренных утечек автоматически и не требует выдавать IQueryable наружу.
Но в остальном вы правы, GraphQL не влечет за собой рассмотренных утечек автоматически и не требует выдавать IQueryable наружу.
Интересно было прочитать об еще существующих ограничениях EF Core. Точно знаю что в linq2db такое я давно сделал и забыл.
А для EF Core есть интересная библиотека для декомпиляции методов: DelegateDecompiler
Мы уже скоро готовы и к таким выкрутасам: https://github.com/linq2db/linq2db/pull/2731
Мир движется и мы не стоим на месте. Бросать LINQ потому-что кто-то решил такое не поддерживать, это не наш путь.
Ну почему же, именно для того мы и вкладывали силы в linq2db — чтобы отчеты создавались легко и непринужденно. Это намного эффективней чем клеить строки в хранимках. А уж ETL на нем пилить одно удовольствие.
А не хотите на DotNext сделать доклад про linq2db?
Черт, это как рассказать про всю Одессу. Что надо рассказывать людям которые думают что EF это вершина ORM, а Dapper классный костыль когда LINQ сливает? Когда они думают одними репозиториями и объектами, а на базу просто ложат болт. Как достучаться?
Сделать хороший доклад: сформулировать проблему, показать примеры сценариев, где linq2db справляется лучше, рассказать о деталях реализации, о технических вызовах, которые пришлось преодолеть при разработке, вставить пару шуточек или мемасиков (со вкусом, не перебарщивая). Навскидку, позиционирование может быть таким: ”linq2db — гибкий как Dapper, но без россыпи SQL в C# коде. Make LINQ great again”:)
Да сравнивать их незачем, разве что по производительности. Внезапно база данных это не набор объектов и если ее так трактовать то имеем то что имеем — через год-полтора в высоконагруженных системах половина кода уходит в хранимки, сущности "аттачатся" для апдейта, удаления, покупаются Zzzz библиотеки. Остается только то что перевести в SQL сил и денег нет.
А потом у вас хранимые процедуры на 1000 строк, которые никто не хочет исправлять, потому что боится что-то сломать. А еще нужно эти процедуры проверять, когда меняется структура БД. В друг какие-то колонки входят в процедуры. LINQ упадет на этапе компиляции. Так что смысл, безусловно, есть.
Если для запроса нужна хранимка на 1000 строк, то в LINQ это будет выглядеть еще ужасней
Ох уж эти теоретики. Ужасен SQL который сложно отдебажить. А LINQ просто разбиваешь на подзапросы, тестируешь их отдельно и объединяешь. И, как показывает практика, часто самая лучшая реализация хранимки по быстродействию — это, черт побери, склейка строк.
К тому же для (снова подчеркну это) именно "отчетных" запросов, т.е. OLAP-задач, по-хорошему должна использоваться отдельная БД со своей схемой
Отчетные, не отчетные. В чем разница? ANSI-SQL никто не отменял. Если LINQ провайдер строит ожидаемый SQL — хоть все процедуры выбрасывай. Да и что тут такого что у них может быть своя схема? (давайте остановимся на реляционках, а то тут можно и до эксцелек дойти)
SQL уступает в том что на нем сложно переиспользовать части кода. Вот тут LINQ рвет его как тузик грелку. Хочешь делать эффективные SQL запросы — делай копипасту.
Транслируй меня полностью