Comments 29
Несмотря на то, что у нас Web API, мы используем метод .AddMvc() вместо .AddControllers(), так как у последнего нет возможности переопределять способ сериализации. Работать наш Web API будет и в рамках MVC.
А куда он делся?
services
.AddControllers()
.AddJsonOptions(options =>
{
options.JsonSerializerOptions.PropertyNamingPolicy = new SnakeCaseNamingPolicy();
});Теперь про ваш ValidationProblemDetailsResult. Не нравится мне что этот класс выбивается из архитектуры ASP.NET Core. Тот код, который у вас написан внутри метода ExecuteResultAsync, я бы поместил прямо в InvalidModelStateResponseFactory. А ещё можно переопределить ProblemDetailsFactory.
Метод ExecuteResultAsync() можно/нужно переписать в виде одного LINQ-выражения. Будет меньше кода, меньше потенциальных ошибок, а так же потрачено меньше памяти и процессора: не нужен ни дополнительный массив, но лист.
В свое время не получилось сделать, чтобы SignalR из MVC5 приложения передавал json в нужном формате. При этом сам ASP.NET данные передавал корректно, это настроить удалось. Может кто сталкивался с таким?
Расширение чужого класса (да еще и string)
Какого "чужого"? А есть такие методы-экстеншены, которые расширяют нечужие классы?
на примере хорошо стилизованного кода
Напишите, пожалуйста, материал, где говорят о том, что именование переменных через с префиксом @ является примером плохо стилизованного кода. В docs.microsoft.com нет подобного "запрета"
Я бы назвал переменную str или value или input. Специально чтобы не добавлять @ но это чистой воды "вкусовщина" — нет ни правых, ни виноватых. Дело вкуса, предпочтений, и личных предрассудков.
Я лично бы действительно не называл переменную string, назвал бы как-либо иначе (см. выше). Я согласен с данной рекомендацией.
Но если на код ревью автор очень хочет так назвать, то я бы не очень сильно сопротивлялся. Важнее сохранить хорошие отношения в команде. А ещё это было бы хорошей "разменной картой" — уступить в одном месте, в обмен на другое изменение.
Иначе говоря, использование переменной @string дозволительно. При этом нет правила в списке https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/style-rules/, использовав который можно было бы запретить это. Даже в приведенной цитате сложность упомянута, но вот в чем сложность заключается — не написано.
Получается, что @string никак не нарушает "хорошо стилизованный код" и является лишь вкусом автора.
Не выдумывайте, пожалуйста. Методы расширения (as in extension methods) созданы специально для… расширения других типов. ToUpper(), ToLower() уже есть, что делает ToSnake() идеальным кандидатом.
Вероятность такой коллизии неотличима от 0.
Вы это "правило" только что придумали. Extension methods созданы для расширения чужих типов, в особенности — встроенных/системных.
Спор за/против extension methods стоит ровно ничего, он бессмысленный и ни к чему не приводит. Потому что в итоге сводится к личным предпочтениям в стиле кода.
Абьюз — плохо, нормальное применение (как в данном случае) — нормально.
Бывает и так.
Но обычно инженеры после 10-15 лет опыта работы приходят к выводу, что из пункта А в пункт Б можно придти разными путями. И если путей видно несколько и ни у одного нет явных недостатков, то выбор — дело вкуса (опыта, предпочтений, предрассудков).
Никаких best practices НЕ использовать extension methods не существует. Вы их выдумали. Насаждать личные предпочтения под видом "правил" — проявление непрофессионализма. А никак не наоборот.
Если я в коде увидел что-нибудь типа SnakeCaseConverter.ToSnakeCase(s) то мне сразу ясно, что это чей-то метод, а если s.ToSnakeCase(), то первое что я подумаю: "WTF? Что это за новый метод у string?"
Это лишь на ваш вкус, что никак не делает его лучше или хуже, чем мой и любых других разработчиков, которые тоже пишут экстеншн-методы к классам в коде, хоть к стандартным из .NET, хоть к самописным
придумано правило "расширяй только свои собственные типы"
Не слышал ранее о таком правиле. Тем не менее, замечание понятно. Но я думаю, что если кто-то пишет код в проекте "по незнанию", то его быстро поправят: либо IntelliSense, либо товарищ на код-ревью.
Какие-то команды действительно могут в своих проектах отказаться от экстеншенов в принципе, но это не повод называть "ужасом" использование экстеншенов в статьях, рассчитанных на широкую аудиторию
Как изменить формат данных JSON на Snake Case в ASP.NET Core Web API