Открыть список
Как стать автором
Обновить

Комментарии 26

Зачем вы так про GraphQL?


Graphql это язык запросов к вашему приложению, он никак не зависит от IQueryable или чего-то ещё — вы сами выбираете (=реализуете) какую фильтрацию поддерживаете.
То есть, он не течёт*, там строгая схема, которую вы сами обязались реализовать.


В HotChocolate (реализация gql для дотнет) 11 версии ребята вообще отказались от IQueryable.


(*может течь, если уровень вложенности select'a становится больше какого-то, задаваемого разработчиком, уровня)

(*может течь, если уровень вложенности select'a становится больше какого-то, задаваемого разработчиком, уровня)

Я имел в виду именно такие варианты. Речь не о IQueryable как таковом, а о том, чтобы выдавать наружу язык запросов. Наверняка существуют API, для которых Graphql — самое то. Но для многих других rest-like вполне достаточно.

Мне казалось, главная-то фишка GraphQL в гибкой настройке возвращаемых объектов, способ организации фильтров — далеко вторичен. Мобилка подтягивает только user {id, firstName}, десктоп — сразу еще и фамилию и вообще весь профиль да еще и всех френдов friends {id, firstName}. GraphQL — это очень удобный способ удовлетворить очень разных потребителей API.

Да, это действительно удобно. С другой стороны и на стороне бекенда это не так сложно сделать на всяких автомаперах/мапстерах. Я думаю, что вопрос больше в том, на сколько разработчики клиентов знакомы с GraphQL и хотят с ним работать.

Нет, конечно ребята не отказались от IQueryable. IQueryable — это по-прежнему единственный дешевый способ получить фильтрацию и пейджинг в HotChocolate из коробки (естественно, в предположении, что эта фильтрация и пейджинг должны в итоге уйти в базу), в остальных — нужно имплементировать фильтрацию самому и, действительно, в HotChocolate v.11 для этого появились точки расширения. Но IQueryable по-прежнему занимает и будет занимать свое место в их архитектуре. На самом деле они отказались (именно об этом говорится в приведенной вами ссылке) от старого АПИ фильтрации — это подробно разбирается здесь. И, разумеется, новое АПИ фильтрации прекрасно работает с IQueryable.

Но в остальном вы правы, GraphQL не влечет за собой рассмотренных утечек автоматически и не требует выдавать IQueryable наружу.
Нет, конечно ребята не отказались от IQueryable. IQueryable — это по-прежнему единственный дешевый способ получить фильтрацию и пейджинг в HotChocolate из коробки (естественно, в предположении, что эта фильтрация и пейджинг должны в итоге уйти в базу), в остальных — нужно имплементировать фильтрацию самому и, действительно, в HotChocolate v.11 для этого появились точки расширения. Но IQueryable по-прежнему занимает и будет занимать свое место в их архитектуре. На самом деле они отказались (именно об этом говорится в приведенной вами ссылке) от старого АПИ фильтрации — это подробно разбирается здесь. И, разумеется, новое АПИ фильтрации прекрасно работает с IQueryable.

Но в остальном вы правы, GraphQL не влечет за собой рассмотренных утечек автоматически и не требует выдавать IQueryable наружу.

GraphQL и OData это ведь просто протоколы поверх HTTP — напрямую они никак с IQueryable не связаны и на сервере могут иметь вообще любую реализацию. Или я что-то путаю?

Я вот об этом


// GET: api/Todo
[EnableQuery()]  // requires using Microsoft.AspNet.OData;
[HttpGet]
public ActionResult<IQueryable<TodoItem>> GetTodoItems()
{
    return _context.TodoItems;
}

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

Интересно было прочитать об еще существующих ограничениях EF Core. Точно знаю что в linq2db такое я давно сделал и забыл.


А для EF Core есть интересная библиотека для декомпиляции методов: DelegateDecompiler

Ну, обычно интуитивно ясно — транслируется ли запрос или нет. Есть, кстати, еще интересная засада. В LINQ-выражении EF при сравнении/сортировке строк будет в итоге использоваться не локаль приложения, а collation сервера БД, т.ч. к этому тоже надо быть готовым.

Мы уже скоро готовы и к таким выкрутасам: https://github.com/linq2db/linq2db/pull/2731
Мир движется и мы не стоим на месте. Бросать LINQ потому-что кто-то решил такое не поддерживать, это не наш путь.

Да, в общем-то, никаких особых сложностей с этим нет, если всего лишь помнить, что для ORM выражение LINQ это вовсе не какие-то операции над объектами CLR, а просто SQL. А то новички, бывает, засунут туда какое-нибудь вычисление двумерного интеграла по поверхности эллипсоида, а потом удивляются, почему у них NotSupportedException. К тому же для тех задач, для которых ORM подходит, выражения обычно очень простые — в >50% случаев это вообще просто поиск сущности по её ID, а использовать ORM, например, для каких-нибудь сложных отчетов это как пилой шурупы закручивать.

Ну почему же, именно для того мы и вкладывали силы в linq2db — чтобы отчеты создавались легко и непринужденно. Это намного эффективней чем клеить строки в хранимках. А уж ETL на нем пилить одно удовольствие.

А не хотите на DotNext сделать доклад про linq2db?

Черт, это как рассказать про всю Одессу. Что надо рассказывать людям которые думают что EF это вершина ORM, а Dapper классный костыль когда LINQ сливает? Когда они думают одними репозиториями и объектами, а на базу просто ложат болт. Как достучаться?

Сделать хороший доклад: сформулировать проблему, показать примеры сценариев, где linq2db справляется лучше, рассказать о деталях реализации, о технических вызовах, которые пришлось преодолеть при разработке, вставить пару шуточек или мемасиков (со вкусом, не перебарщивая). Навскидку, позиционирование может быть таким: ”linq2db — гибкий как Dapper, но без россыпи SQL в C# коде. Make LINQ great again”:)

Что надо рассказывать людям которые думают что EF это вершина ORM

Да, но linq2db (как и Dapper), как я увидел, это, все-таки, вовсе не ORM и не претендует им быть, о чем в самом начале документации открыто и говорится. И сравнивать его с EF или Hibernate смысла не больше чем сравнивать карьерный самосвал и городскую малолитражку.

Да сравнивать их незачем, разве что по производительности. Внезапно база данных это не набор объектов и если ее так трактовать то имеем то что имеем — через год-полтора в высоконагруженных системах половина кода уходит в хранимки, сущности "аттачатся" для апдейта, удаления, покупаются Zzzz библиотеки. Остается только то что перевести в SQL сил и денег нет.

А есть ли большой смысл вообще использовать LINQ для "отчетных" запросов? SQL это очень развитый, богатый язык созданный именно для написания запросов. LINQ удобней чем SQL только тогда, когда надо реляционную БД подружить с объектной моделью и объектной БЛ. Во всем остальном LINQ всегда будет SQL уступать, хотя бы потому, что все равно будет требовать трансляции в тот же SQL.

А потом у вас хранимые процедуры на 1000 строк, которые никто не хочет исправлять, потому что боится что-то сломать. А еще нужно эти процедуры проверять, когда меняется структура БД. В друг какие-то колонки входят в процедуры. LINQ упадет на этапе компиляции. Так что смысл, безусловно, есть.

Если для запроса нужна хранимка на 1000 строк, то в LINQ это будет выглядеть еще ужасней. К тому же для (снова подчеркну это) именно "отчетных" запросов, т.е. OLAP-задач, по-хорошему должна использоваться отдельная БД со своей схемой, а то и вообще другие инструменты, которые выходят за рамки RDB и SQL. А на такой БД запросов в 1000 строк не будет, потому что именно для этого она и создается.

Если для запроса нужна хранимка на 1000 строк, то в LINQ это будет выглядеть еще ужасней

Ох уж эти теоретики. Ужасен SQL который сложно отдебажить. А LINQ просто разбиваешь на подзапросы, тестируешь их отдельно и объединяешь. И, как показывает практика, часто самая лучшая реализация хранимки по быстродействию — это, черт побери, склейка строк.


К тому же для (снова подчеркну это) именно "отчетных" запросов, т.е. OLAP-задач, по-хорошему должна использоваться отдельная БД со своей схемой

Отчетные, не отчетные. В чем разница? ANSI-SQL никто не отменял. Если LINQ провайдер строит ожидаемый SQL — хоть все процедуры выбрасывай. Да и что тут такого что у них может быть своя схема? (давайте остановимся на реляционках, а то тут можно и до эксцелек дойти)

Отчетные, не отчетные. В чем разница?

Ну, если так, то ладно :)

SQL уступает в том что на нем сложно переиспользовать части кода. Вот тут LINQ рвет его как тузик грелку. Хочешь делать эффективные SQL запросы — делай копипасту.

Кроме этого C#-код лежит себе спокойненько в репозитории. Для него божественный тулинг, его можно разложить по папкам, а хранимок будет простыня в БД:)

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