IEntityTypeConfiguration в EF Core, или отделим отделимое

Эта статья - мнение, кому-то может оказаться полезной.

Ну и если бы тема статьи была - "EF Core - про миграции и вагон всего..." то обязательно бы раскрыли эти вещи, не переживайте😉

Упрощаем себе жизнь при разработке интерфейса взаимодействия приложения и БД

В этом нет ничего такого. Возможно до этого человек просто не пользовался ORM-фреймворками и для него это что-то новое. Или же, он устал от того, что на работе упорно отрицают такие инструменты, предпочитая "по-старинке" осуществлять взаимодействие с БД.

В любом случае я уверен, что свой читатель под это найдётся, ведь например, только выпустившиеся инженеры и знать не знают о таких инструментах, а тут без лишней воды своеобразный Quick start guide🙂

IEntityTypeConfiguration в EF Core, или отделим отделимое

Всё как бы верно, но:
На проект может попасть новый разработчик, который в принципе не слышал о таких соглашениях, и, для наглядности и более быстрого онбординга коллеги как раз такое конфигурирование (кроме builder.HasKey(k => k.Id)) будет очень даже полезным.

IEntityTypeConfiguration в EF Core, или отделим отделимое

Согласен

IEntityTypeConfiguration в EF Core, или отделим отделимое

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

Конфигурация сущностей в EF Core

Как сказали несколькими комментариями выше - это всё вкусовщина, особенно на текущих примерах. Разницу по функциональности способов мы рассмотрим в следующих статьях.

Конфигурация сущностей в EF Core

Мне больше по душе, чтобы слои были строго разделены между собой и являлись слабосвязанными. Для меня однозначно - POCO-объекты должны маппиться в объекты домена. Более глубоко данного вопроса мы коснёмся в следующей статье.
Спасибо за фидбек!

Конфигурация сущностей в EF Core

Полностью согласен с Вами.

Конфигурация сущностей в EF Core

Ну а если ещё добавить summary к каждому свойству, и свойств будет более 2-3 и настроить маппинг на поля объектов БД надо будет более тонко? Например:

    [Table("Cars")]
    public class CarEntity
    {
        /// <summary>That represents unique identifier</summary>
        [Key]
        public Guid Id { get; set; }
        /// <summary>That represents make of vehicle and null input not allowed</summary>
        [Column("Make", TypeName = "varchar2")]
        [MaxLength(16)]
        [Required]
        public string Make { get; set; }
        /// <summary>That represents model of vehicle and null input is not allowed</summary>
        [Column("Model", TypeName = "varchar2")]
        [MaxLength(26)]
        [Required]
        public string Model { get; set; }
        /// <summary>That represents production year of vehicle</summary>
        [Column("Year")]
        public int ModelYear { get; set; }
        /// <summary>That represents VIN (vehicle identifier) of vehicle and null input is not allowed</summary>
        [Column("VIN", TypeName = "varchar2")]
        [MaxLength(14)]
        [Required]
        public string Vin { get; set; }
        /// <summary>That represents color of vehicle</summary>
        [Column("Color", TypeName = "varchar2")]
        [MaxLength(16)]
        public string Color { get; set; }
    }

Уже не так читабельно (как по мне), согласитесь?

Конфигурация сущностей в EF Core

Ну как правило, слои разделяют, и, соответственно - доменные сущности будут "жить" в слое для реализации доменной логики и ничего не знать о деталях реализации работы с БД. А вот наши классы-сущности в слое доступа к данным, так что и атрибуты подойдут, если не много объектов. Но в любом случае - спасибо за столь ёмкую обратную связь!
Это тема для следующей статьи, кстати)

Конфигурация сущностей в EF Core

Спасибо большое за фидбек!

Dependency Injection в .NET на почтальонах

Ну вроде со своей стороны ерунды я не увидел. DI является формой реализации IoC и IoC также может иметь несколько других форм реализации.
Спасибо за разъяснение - очень удачное.

Dependency Injection в .NET на почтальонах

DI - это способ инверсии управления насколько я знаю. Инвертировать же управление можно не только внедряя зависимости.
Но каждый имеет право на своё мнение, так что я думаю можно и прекратить дискуссию.

Dependency Injection в .NET на почтальонах

Инверсия управления, это один паттернов проектирования, принципов объектного программирования, который имеет несколько способов реализации, в число которых и входит внедрение зависимостей.
Также он может быть реализован через паттерн "Фабрика", через локатор служб.
Так что приведенное мной утверждение про то, что DI является формой IoC - полностью верно.

Dependency Injection в .NET на почтальонах

Добрый день!
Нет, это отношение не симметрично. Разрешаться scoped зависимость будет как обычно.