Как изменить формат данных JSON на Snake Case в ASP.NET Core Web API

[mayorovp]

Несмотря на то, что у нас Web API, мы используем метод .AddMvc() вместо .AddControllers(), так как у последнего нет возможности переопределять способ сериализации. Работать наш Web API будет и в рамках MVC.

А куда он делся?

            services
                .AddControllers()
                .AddJsonOptions(options =>
                {
                    options.JsonSerializerOptions.PropertyNamingPolicy = new SnakeCaseNamingPolicy();
                });

---

Теперь про ваш ValidationProblemDetailsResult. Не нравится мне что этот класс выбивается из архитектуры ASP.NET Core. Тот код, который у вас написан внутри метода ExecuteResultAsync, я бы поместил прямо в InvalidModelStateResponseFactory. А ещё можно переопределить ProblemDetailsFactory.

[maximgorbatyuk]

.AddControllers()

Действительно так. Исправлю в статье. Спасибо за замечание

[abatishchev]

Метод ExecuteResultAsync() можно/нужно переписать в виде одного LINQ-выражения. Будет меньше кода, меньше потенциальных ошибок, а так же потрачено меньше памяти и процессора: не нужен ни дополнительный массив, но лист.

[maximgorbatyuk]

Спасибо за рекомендацию

[SHTrassEr]

В свое время не получилось сделать, чтобы SignalR из MVC5 приложения передавал json в нужном формате. При этом сам ASP.NET данные передавал корректно, это настроить удалось. Может кто сталкивался с таким?

[maximgorbatyuk]

Расширение чужого класса (да еще и string)

Какого "чужого"? А есть такие методы-экстеншены, которые расширяют нечужие классы?

на примере хорошо стилизованного кода

Напишите, пожалуйста, материал, где говорят о том, что именование переменных через с префиксом @ является примером плохо стилизованного кода. В docs.microsoft.com нет подобного "запрета"

[abatishchev]

Я бы назвал переменную str или value или input. Специально чтобы не добавлять @ но это чистой воды "вкусовщина" — нет ни правых, ни виноватых. Дело вкуса, предпочтений, и личных предрассудков.

[abatishchev]

Я лично бы действительно не называл переменную string, назвал бы как-либо иначе (см. выше). Я согласен с данной рекомендацией.

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

[maximgorbatyuk]

Если заранее список подобных мини-запретов на команду не определён, то каждый участник этой команды действительно может писать код как ему вкус позволяет. Конечно же, в рамках принятого код-стайла языка/фреймворка.

[maximgorbatyuk]

Иначе говоря, использование переменной @string дозволительно. При этом нет правила в списке https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/style-rules/, использовав который можно было бы запретить это. Даже в приведенной цитате сложность упомянута, но вот в чем сложность заключается — не написано.

Получается, что @string никак не нарушает "хорошо стилизованный код" и является лишь вкусом автора.

[abatishchev]

Не выдумывайте, пожалуйста. Методы расширения (as in extension methods) созданы специально для… расширения других типов. ToUpper(), ToLower() уже есть, что делает ToSnake() идеальным кандидатом.

[abatishchev]

Вероятность такой коллизии неотличима от 0.

Вы это "правило" только что придумали. Extension methods созданы для расширения чужих типов, в особенности — встроенных/системных.

Спор за/против extension methods стоит ровно ничего, он бессмысленный и ни к чему не приводит. Потому что в итоге сводится к личным предпочтениям в стиле кода.

Абьюз — плохо, нормальное применение (как в данном случае) — нормально.

[abatishchev]

Бывает и так.

Но обычно инженеры после 10-15 лет опыта работы приходят к выводу, что из пункта А в пункт Б можно придти разными путями. И если путей видно несколько и ни у одного нет явных недостатков, то выбор — дело вкуса (опыта, предпочтений, предрассудков).

Никаких best practices НЕ использовать extension methods не существует. Вы их выдумали. Насаждать личные предпочтения под видом "правил" — проявление непрофессионализма. А никак не наоборот.

[maximgorbatyuk]

Если я в коде увидел что-нибудь типа SnakeCaseConverter.ToSnakeCase(s) то мне сразу ясно, что это чей-то метод, а если s.ToSnakeCase(), то первое что я подумаю: "WTF? Что это за новый метод у string?"

Это лишь на ваш вкус, что никак не делает его лучше или хуже, чем мой и любых других разработчиков, которые тоже пишут экстеншн-методы к классам в коде, хоть к стандартным из .NET, хоть к самописным

[maximgorbatyuk]

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

[mayorovp]

Ну так string — не object, от него ничего не наследуется.

[abatishchev]

Вам не нравятся extensions methods, мы уже поняли :)

[abatishchev]

По-моему — ровно наоборот. Я не люблю статические публичные хелперы, типа Utils.DoSomething(foo, 44). Вместо них предпочитаю extensions methods.

[maximgorbatyuk]

придумано правило "расширяй только свои собственные типы"

Не слышал ранее о таком правиле. Тем не менее, замечание понятно. Но я думаю, что если кто-то пишет код в проекте "по незнанию", то его быстро поправят: либо IntelliSense, либо товарищ на код-ревью.

Какие-то команды действительно могут в своих проектах отказаться от экстеншенов в принципе, но это не повод называть "ужасом" использование экстеншенов в статьях, рассчитанных на широкую аудиторию