Какие-то данные это филды? То есть как сделать так чтобы при запросе user поле name возврачалось всем, а email только админу? Просто на резолвер email устанавливаете другие валидации. Если ты не админ и запросил поле email получаешь 403. Хотите пример кода с GraphQL.Net?
Простите, но я люблю писать код. За поддержку OSS проекта у меня есть бесплатный Copilot Pro и я периодически пытаюсь им пользоваться. Если обычно я пишу код и получаю от этого удовольствие, то с Copilot я делаю бесконечные code review. Он мне код, я ему комментарий. И так по кругу. Причем его изменения всегда непередсказуемые и приходится перечитывать весь код сначала. Раз за разом. Час за часом. Если человеку в ревью можно коротко написать, что не так, то ему нужно разжевать иначе его опять понесет ни туда. Удовольствия от работы ни остается от слова совсем.
Не. Там struct передается в object, то есть будет выполняться boxing. Нет смысла сравнивать ссылки объектов, если для одного объекта будет выделяться новое место в куче при каждом вызове этой функции. Результат всегда будет false.
Вы путаете DI (или IoC) и IoC Container. Первый о том что класс не создает зависимости для самого себя. Второй - фреймворк который резолвит эти зависимости для класса. Прокидывает он их через конструктор (хорошо) или свойства (зло! Не делай так!). В статье используется так называемый Poor man DI. Пишу с телефона, лень умные ссылки добавлять. Если очень надо, то конечно добавлю.
Ненавижу удаленку. Времена короны были для меня испытанием. Я не люблю людей и большую часть дня в офисе я ни с кем не общаюсь, но там я чувствую себя гораздо комфортней. Думаю дело в размере помещения. В квартире на тебя давят стены и потолок. В офисе, пространство гораздо больше и огромные окна на всю стену.
Неужели вам нужно все разжевывать? Неужели не понятно что речь идет о том, что есть асинхронная версия с BeginInvoke? Мы в 2012, помните?Вместо того чтобы сосредотояится на главном, вы вылавливаете всякие закавырки не сказаные напрямую и придераетесь к ним, уходя от основной темы разговора. Просто поразительно насколько плохо у вас с абстрактным мышлением.
Статья Стивена Клери не появилась на пустом месте. В 2012 году C# показал людям что можно писать код, который выглядит как синхронный, но по факту имеет преимущества асинхронного. И людям было сложно понять эту магию. Все таки много лет они мыслили синхронными методами. Давайте возьмем простой пример, что бы понять в чем была сложность и почему появилась та статься.
Вот вам код:
public void DoSomeWork()
{
Console.WriteLine("Getting string...");
var str = GetString();
Console.WriteLine($"Received string {str}");
}
public string GetString()
{
var request = CreateRequest();
var response = ExecuteRequest(request);
var responseString = response.GetString();
return responseString;
}
Программист мыслил так:
Сначала мой код выведет `Getting string...`
Потом создаст запрос и отправит его на выполнение
Тут я буду ждать ответа, и только когда он вернется, я вытащу из него строку и выведу результат на экран
Это не эфективно, но зато прямоленейно, легко пишется и читается.
Я могу запустить ExecuteRequest асинхронно, но тогда мой код после этого вызова продолжит выполняться не дожидаясь ответа. То есть эти строки выполнятся хотя я еще не получил ответ:
var responseString = response.GetString();
return responseString;
Console.WriteLine($"Received string {str}");
Но это сломает программу поэтому мне нужно написать ее иначе. Нужно перекинуть продолжение в асинхронный колбэк. Если продолжение метода GetString это не сложно, то вот с DoSomeWork уже сложнее.
А что если перед DoSomeWork есть еще длиннющая цепочка вызовов?
Ну его нафиг, я просто использую синхронный вызов.
И тут приходит C# 5 и говорит: не надо менять структуру кода, просто добавть пару волшебных слов и все станет ассинхонным.
И программист такой: но как же так? Ведь response.GetString(); будет выполнен до окончания ExecuteRequest. Это сломает мой код!
C#: нет нет, твой код не продолжит выполнение. Он будет как бы заблокирован, но не заблокирован. Вот такая вот магия.
Программист: мне кажется ты лжешь. Ты запустишь где-то поток, который будет ждать ответа, а потом как-то вернешь управлнеие мне что бы я продолжил с того же места где закончил. Я не вижу колбэков! Кто-то должен дождаться ответа!
И вот это было самым сложным для понимания. Код выглядил линейным но выполнялся асинхронно. Все задавали этот вопрос, и Стивен прекрасно справился с ответом.
https://github.com/graphql-dotnet/server/blob/master/samples/Samples.Authorization/Schema/Query.cs#L15
Какие-то данные это филды? То есть как сделать так чтобы при запросе user поле name возврачалось всем, а email только админу? Просто на резолвер email устанавливаете другие валидации. Если ты не админ и запросил поле email получаешь 403. Хотите пример кода с GraphQL.Net?
Простите, но я люблю писать код. За поддержку OSS проекта у меня есть бесплатный Copilot Pro и я периодически пытаюсь им пользоваться. Если обычно я пишу код и получаю от этого удовольствие, то с Copilot я делаю бесконечные code review. Он мне код, я ему комментарий. И так по кругу. Причем его изменения всегда непередсказуемые и приходится перечитывать весь код сначала. Раз за разом. Час за часом. Если человеку в ревью можно коротко написать, что не так, то ему нужно разжевать иначе его опять понесет ни туда. Удовольствия от работы ни остается от слова совсем.
Простите, я для этого не нанимался.
11 of the most costly software errors in history · Raygun Blog
Но здесь передается
this, а не кешированый бокс, так что все равно будетfalseНе. Там struct передается в object, то есть будет выполняться boxing. Нет смысла сравнивать ссылки объектов, если для одного объекта будет выделяться новое место в куче при каждом вызове этой функции. Результат всегда будет false.
Где примеры использования? Где side-by-side сравнение кода? Простите, но статья пустая. Что-то там восхваляется, но эти фанфары ничем не подтверждены.
Вы путаете DI (или IoC) и IoC Container. Первый о том что класс не создает зависимости для самого себя. Второй - фреймворк который резолвит эти зависимости для класса. Прокидывает он их через конструктор (хорошо) или свойства (зло! Не делай так!). В статье используется так называемый Poor man DI. Пишу с телефона, лень умные ссылки добавлять. Если очень надо, то конечно добавлю.
А я думал чтобы как раз таки было можно. Без CORS все запрещено, а при включении CORS - немножечко можно.
То есть у вас не было ни одного хотя бы мидл разработчика, который бы вам сказал, что вы все не правильно делаете?
Не нужно.
И не нужно.
https://youtu.be/jOTM9T59IX4?si=23YQ3ECRo0lb2UYv
Ненавижу удаленку. Времена короны были для меня испытанием. Я не люблю людей и большую часть дня в офисе я ни с кем не общаюсь, но там я чувствую себя гораздо комфортней. Думаю дело в размере помещения. В квартире на тебя давят стены и потолок. В офисе, пространство гораздо больше и огромные окна на всю стену.
Какое соревнование? Вы о чем вообще? Этот коментарий такой же бессмысленный как и предыдущий. Как и ваши последние статьи, к слову.
На личность перешли? А еще ниже можете?
Хватит. То что вы перевели статью от Тауба про async/await не делает вас экспертом в этой теме. Хватить писать эту псевдонаучную ересь.
Неужели вам нужно все разжевывать? Неужели не понятно что речь идет о том, что есть асинхронная версия с BeginInvoke? Мы в 2012, помните?Вместо того чтобы сосредотояится на главном, вы вылавливаете всякие закавырки не сказаные напрямую и придераетесь к ним, уходя от основной темы разговора. Просто поразительно насколько плохо у вас с абстрактным мышлением.
Статья Стивена Клери не появилась на пустом месте. В 2012 году C# показал людям что можно писать код, который выглядит как синхронный, но по факту имеет преимущества асинхронного. И людям было сложно понять эту магию. Все таки много лет они мыслили синхронными методами. Давайте возьмем простой пример, что бы понять в чем была сложность и почему появилась та статься.
Вот вам код:
Программист мыслил так:
Сначала мой код выведет `Getting string...`
Потом создаст запрос и отправит его на выполнение
Тут я буду ждать ответа, и только когда он вернется, я вытащу из него строку и выведу результат на экран
Это не эфективно, но зато прямоленейно, легко пишется и читается.
Я могу запустить
ExecuteRequestасинхронно, но тогда мой код после этого вызова продолжит выполняться не дожидаясь ответа. То есть эти строки выполнятся хотя я еще не получил ответ:Но это сломает программу поэтому мне нужно написать ее иначе. Нужно перекинуть продолжение в асинхронный колбэк. Если продолжение метода
GetStringэто не сложно, то вот сDoSomeWorkуже сложнее.А что если перед
DoSomeWorkесть еще длиннющая цепочка вызовов?Ну его нафиг, я просто использую синхронный вызов.
И тут приходит C# 5 и говорит: не надо менять структуру кода, просто добавть пару волшебных слов и все станет ассинхонным.
И программист такой: но как же так? Ведь
response.GetString();будет выполнен до окончанияExecuteRequest. Это сломает мой код!C#: нет нет, твой код не продолжит выполнение. Он будет как бы заблокирован, но не заблокирован. Вот такая вот магия.
Программист: мне кажется ты лжешь. Ты запустишь где-то поток, который будет ждать ответа, а потом как-то вернешь управлнеие мне что бы я продолжил с того же места где закончил. Я не вижу колбэков! Кто-то должен дождаться ответа!
И вот это было самым сложным для понимания. Код выглядил линейным но выполнялся асинхронно. Все задавали этот вопрос, и Стивен прекрасно справился с ответом.