Required. Что скрыто в этом слове?

[WhiteBehemoth]

1. Required используем для строк. Но есть нюанс (*).

Это не нюанс, это нюансище. Чтоб опущенный параметр для всяких Int или Guid выкидывал ошибку валидации, а не инициализировался "по умолчанию".

Будьте внимательны в использовании слова required где бы то ни было в проекте

Мы в конце концов практически отказались от него. Хлопот больше, чем реальной пользы.

[ProgerMan]

Для других типов я предпочитаю использовать более конкретные атрибуты, вроде Range или прочие самописные (например, IsPositive). А для более сложных валидаций пишу валидаторы, которые заполняют ModelState ошибками.

[AgentFire]

А мы наоборот, используем в своих DTO его по максимуму. Польза: мы всегда уверены, что все нужные поля будут проинициализировано любым пользователем DTO. Хлопот никаких нет. А какие они у вас?

[ProgerMan]

В своих проектах всё, что можно провалидировать атрибутами, валидирую атрибутами. От этого особенно выигрывают проекты на Blazor, т.к. там это работает, как на сервере, так и на клиенте.

[AgentFire]

Простите, а причем тут валидация? Речь про required, не [Required].

[WhiteBehemoth]

required в DTO даже не думали. У нас вся валидация через атрибуты. (DTO используется только API на базе ASP.NET). Интересно, если required поле не было в приходящем json объекте, ASP.NET возвращает такой же 400 bad request с пропущенным полем, как и с [Required] атрибутом?
Хлопоты, про которые я говорил - накладываемые ограничения, типа конструктора без параметров. Мы хотели убрать null! инициализацию для not nullable properties, но оказались не готовы для этого менять логику.

[AgentFire]

Все еще непонятно, причем тут какая-то валидация. Ключевое слово required вообще с ней никак не связано.

Хлопоты, про которые я говорил - накладываемые ограничения, типа конструктора без параметров.

Но ведь с required конструктор всё еще запросто может быть без параметров. Что я не так понял в вашем сообщении?

Мы хотели убрать null! инициализацию для not nullable properties, но оказались не готовы для этого менять логику.

Снова непонятно. Вы осознанно поощряете отсутствие инициализации некоторых полей, но введение required, которое вам бы прогарантировало исправление данной ситуации, вы называете "не готовы менять логику" — т.е. по факту не готовы вручную проинициализировать все пропущенные поля, и сиё утверждение считаете достаточным аргументом против required? Всё так понял, или я снова затупил?

[AgentFire]

Либо required, либо nullable.

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

А я вот поделюсь своим личным мнением, для чего оно нужно. На мой взгляд, его единственная цель - это не дать забыть про инициализацию этого поля разработчиком, который пишет new().

В этом случае как тип, так и nullability поля не имеет значения. На разработчика накладывается обязательство explicitly (-over implicitly) указать изначальное значение, даже если оно null/default.

Таким образом чтение кода сильно упрощается - в будущем любому читающему не будет непонятно, писатель кода забыл указать значение, или же оно там действительно должно быть проинициализировано значением "null".

[ProgerMan]

Я не вижу ни одного реального примера, для которого может понадобиться обязательно указывать null для nullable. Допустим, сделали неявное явным, но как это поможет? На мой взгляд это лишь загромождает код. Если в дальнейшем коде устраивает значение по умолчанию, то модификатор required не нужен.

[AgentFire]

Я же русским по темному написал обоснование необходимости и как именно это поможет, аж в двух местах.

[WhiteBehemoth]

как пример - вы допускаете установку поля в null, но хотите избежать случайного обнуления (когда поле просто случайно опущено).