энтити-класс (dto) должен быть только корзиной для данных из/в бд. дальше делай отдельные модели промежуточные, или финальные viewModel, готовые к отправке на фронт

ню да

это я и понял

пасибо

Откуда эта мода делать всё в процедурном стиле, отдельно описывать данные и логику над ними? Это из-за непонимания ООП, недостатка знаний о нем, непонятно...

Это от суровой действительности где ты гоняешь данные и выполняешь над ними действия

Что же это за данные и действия такие специфические?

Ну вот отличный вопрос на порассуждать в воскресенье. На примере, например.
Вот у меня есть пользователь. И мне нужно его аутентифицировать.
Как оно сейчас? Сервис аутентификации, метод LogOn(login, password), возвращает экземпляр User. User - простейшее DTO. Ну там, FirstName, LastName, Login, Email и т.д.
Если мы объединяем логику работы с данными и сами данные, то тогда как?
В конструкторе? Типа: new User(login, password) и лезем в базу? Да не, нельзя. У нас же везде async / await.
Тогда
var user = new User();
await user.LogOn(login, password);
-> user.Email => "user@domain.com"

var user2 = new User();
-> user.Email => throw new EntityStateException("Entity is not initialized")
Так получается?

Или логику аутентификации нельзя объединять в класс пользователя. Хорошо. А что тогда можно?
Добавление ролей?
await user.AddRole(role);
await user.AddRoles(role1, role2, role3);
-> user.Roles => [role, role1, role2, role3]
Ну, терпимо... Типа, можно одному пользователю сразу несколько ролей назначить.
Теперь аналогичное, но наоборот. В одну роль несколько пользователей. Хм...

await role.AddUsers(user1, user2, user3);
-> role.Users => [user1, user2. user3]
и, при этому
-> user1.Roles => [role]

Блин, чересчур сильная связность. Любое изменение role в одном месте (название поменяли), ведёт к необходимости отследить все активные экземпляры User  и поменять в коллекции ролей ту, которая изменилась. И это только в случае, если участвуют два связанных между собой класса - User и Role. В enterprise всякие сущности имеют немного сильно больше связей между собой.

Ладно, через свойства нельзя. Можно, но видим, что есть проблемы. Давайте через методы.

await user.GetRoles() => [role]
await role.GetUsers() => [user1, user2, user3]

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

await company.GetUsers() => [user1, user2, user3]
await department1.GetUsers() => [user2, user3]
await department2.GetUsers() => [user1, user3]
await document1.GetAuthors() => [user3]

Тогда всплывает вопрос, а что внутри у этим методов, которые получают пользователей? Некий общий класс доступа к БД, который работает с таблицей Users и возможными связями?
То есть, везде у нас будет

class Role {
 Task<IEnumerable<User>> GetUsers() {
   return _userService.GetUsersByRoleId(this.Id)
 }
}

так получается?

То есть, надо как-то заинжектить этот сервис во все классы.

канеш, наследование-то ты просрал когда от ооп отказался и обратно забыл впиздрючить когда решил поиграть в отрицателя, но допустителя

Давай подумаем в наследование. Куда его тут?

ну вот как минимум во все классы ничо инжектить не надо, инжектить это уже не про ооп, а про процедурные залупы

просто наследника от того кто этот метод уже имеет

Тема для вечного срача. Я лично за то, что оба стиля дополняют друг друга

Разбираем по пунктам.
1. Инжектить ничего не надо. Тогда как?
В конструкторе базовой сущности читаем из конфигурации строку подключения к БД? И дальше наследники используют её в своих конструкторах, чтобы инициализировать экземпляры классов для доступа к БД? Не, тоже не канает. Просто строки подключения мало. Надо какой-то контекст, чтобы можно было транзакционно работать с несколькими сущностями. Типа
var tran = _context.BeginTran();
await user.AddRole(role1);
await company.AddUser(user)
tran.Commit();
Ну допустим. И ссылка на контекст - в базовом классе.

2. Множественное наследование до 8 шарпа пока ещё не очень. Так что, только интерфейсы.
await company.AddUsers(user1, user2)
await company.AddDepartments(department1)
await company.AddRole(role1)
при этом
await department1.AddUsers(user1)
await role1.AddUsers(user2)

У них общий предок? Вряд ли. Скорее часть интерфейсов, которые они реализуют, пересекаются. Просто потому что реализация AddUsers у них разная.

а для разной реализации есть виртуальные методы, опана

Супер полезно... А можно теперь предметно? Что из перечисленного выше имеет право на жизнь? А где dto+service - рулят?