Как стать автором
Поиск
Написать публикацию
Обновить

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

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


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


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


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

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

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

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

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

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

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

Но в остальном вы правы, GraphQL не влечет за собой рассмотренных утечек автоматически и не требует выдавать IQueryable наружу.
Всего голосов 1: ↑1 и ↓0+1
НЛО прилетело и опубликовало эту надпись здесь

Я вот об этом


// GET: api/Todo
[EnableQuery()]  // requires using Microsoft.AspNet.OData;
[HttpGet]
public ActionResult<IQueryable<TodoItem>> GetTodoItems()
{
    return _context.TodoItems;
}
Комментарий пока не оценивали0
НЛО прилетело и опубликовало эту надпись здесь

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


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

Комментарий пока не оценивали0
НЛО прилетело и опубликовало эту надпись здесь

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

Комментарий пока не оценивали0
НЛО прилетело и опубликовало эту надпись здесь

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

Всего голосов 1: ↑1 и ↓0+1

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

Всего голосов 1: ↑1 и ↓0+1

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

Комментарий пока не оценивали0

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

Всего голосов 1: ↑1 и ↓0+1
НЛО прилетело и опубликовало эту надпись здесь

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

Всего голосов 1: ↑1 и ↓0+1
НЛО прилетело и опубликовало эту надпись здесь

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

Всего голосов 1: ↑1 и ↓0+1
НЛО прилетело и опубликовало эту надпись здесь
Если для запроса нужна хранимка на 1000 строк, то в LINQ это будет выглядеть еще ужасней

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


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

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

Всего голосов 1: ↑1 и ↓0+1
НЛО прилетело и опубликовало эту надпись здесь

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

Всего голосов 2: ↑2 и ↓0+2

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

Всего голосов 1: ↑1 и ↓0+1

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

Комментарий пока не оценивали0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Показать лучшие за всё время
Разблокировать темную тему

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr