Комментарии 11
Всё, как бы верно, но только как пример, потому что на самом деле, в данном случае это все не нужно. Id будет автоматически ключом по соглашению, IsRequired будет добавлен или не добавлен на основе nullable/not-nullable типов свойств. Единственно что нужно это MaxLength, но вот как раз его-то лучше задать аттрибутом свойства, потому что это больше свойство самого домена/модели, а не меппинга данных.
И еще, я бы не увлекался наследованием в моделях - из личного опыта, если модель начинает хоть немного усложняться и разрастаться, то это порождает намного больше проблем, чем сначала дает выгоды.
Поддерживаю, однако вот вынесение таких полей, как идентификатор, даты удаления/создания в базовый класс все же считаю допустимым. Но в остальном да, лучше не увлекаться наследованием
Наследование нам может помочь в будущем в дженерик репо/сервисах. Но если не хочется прибегать к базовой сущности, то можно с этими общими полями определить интерфейс, вместо базового класса, чтобы также иметь все преимущества дженериков в будущем.
Ну так вот именно, что намного лучше интерфейс, хотя это и стоит дополнительного кода. А иначе потом окажется, что в десятой сущности Id должен по какой-то причине быть не гуидным, а численным, в одинадцатой ничего никогда не обновляется поэтому UpdateDate там вообще лишний и так далее, и со временем вся эта изначальная красота с EntityBase превращается в полный бедлам в котором одни сущности наследуют от EntityBase, другие от какого-нибудь EntityBase2, третьи вообще ни от чего не наследуют, и тут появляются какие-то еще, которые вообще непонятно куда в эту имеющуюся схему пристроить. Наследование с целью полиморфизма (т.е. те же интерфейсы) это хорошо, но наследование с целью просто повторного использования кода далеко не всегда, и чаще всего это наоборот плохо и чревато последующими проблемами - про это уже давно писали и Саттер и Александреску, и Рихтер. Это как с принципом KISS - с одной стороны он правильный, а с другой стороны регулярно видишь, как создание разделямого кода для применения этого принципа превращается в еще большее зло чем дублирование этого кода.
Всё как бы верно, но:
На проект может попасть новый разработчик, который в принципе не слышал о таких соглашениях, и, для наглядности и более быстрого онбординга коллеги как раз такое конфигурирование (кроме builder.HasKey(k => k.Id)) будет очень даже полезным.
Да и virtual в ссылках на связанные сущности является пережитком старого Entity Framework и абсолютно избыточен, если только вы не хотите использовать Lazy loading.
Реально про такое статью надо написать? Тут уровень ниже плинтуса...
Хоть бы рассмотрели вопросы наследования в реальном проекте. Как его маппит ef, миграции и другие тонкости. Там вагон всего.
IEntityTypeConfiguration в EF Core, или отделим отделимое