Size: a a a

var chat = new Chat();

2020 April 12

G

Gopneg in var chat = new Chat();
Name => "Kyryll";
Просто в ASP.NET Core DI из коробки, а Gopneg не любит все что с Core связано => ерго инжектить не надо, надо в констуркторе зависимости создавать. Yay!
я вообще еще не высказывал своего мнения по поводу процедурного стиля инжектов
просто обосрал чужое
источник

N

Name => "Kyryll"; in var chat = new Chat();
Gopneg
я вообще еще не высказывал своего мнения по поводу процедурного стиля инжектов
просто обосрал чужое
Так вьісказьівай свое, так конструктивнее будет.
источник

A

Andrew in var chat = new Chat();
Gopneg
я вообще еще не высказывал своего мнения по поводу процедурного стиля инжектов
просто обосрал чужое
констурктивно 🤔
источник

G

Gopneg in var chat = new Chat();
Name => "Kyryll";
Так вьісказьівай свое, так конструктивнее будет.
зачем я буду ему подсказывать правильные ответы? пусть крутится как уж на сковородке, раз высунулся
источник

YN

Yurii Nskyi in var chat = new Chat();
Dmytro Bardai
Или логику аутентификации нельзя объединять в класс пользователя. Хорошо. А что тогда можно?
Добавление ролей?
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]
2. мы можем добавить и роль пользователю, и пользователей в роль, здесь возможны оба варианта, НО для избежания сильной связности стоит правильно формировать связи между сущностями, у тебя пользователь и роль это две отдельные сущности, достаточно в пользователе хранить список айдишников ролей и это всё из ролей что потребуется трекать в пользователе
3. пример с компаниями и департаментами вполне себе валидный, хочешь получить пользователей, добавляй соответствующий метод, или обобщай это всё отдельный класс/интерфейс
источник

YN

Yurii Nskyi in var chat = new Chat();
Dmytro Bardai
Тогда всплывает вопрос, а что внутри у этим методов, которые получают пользователей? Некий общий класс доступа к БД, который работает с таблицей Users и возможными связями?
То есть, везде у нас будет

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

так получается?
4. такого вопроса даже не всплывает, у них тупейший возврат внутренней коллекции, которая хранит этих пользователей. ЭТИ СУЩНОСТИ НЕ РАБОТАЮТ С БАЗОЙ! иначе ты описываешь известный антипаттерн Active Record
источник

YN

Yurii Nskyi in var chat = new Chat();
Dmytro Bardai
Разбираем по пунктам.
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 у них разная.
1. Active Record, а мы уже разобрались что это плохо, нарушает все возможные принципы, но это невероятно легко использовать поначалу, по наивности
2. эти методы AddUsers возникают не на пустом месте, и понятие DRY здесь не применимо, это бизнес-логика твоего приложения, логика добавления пользователей вообще говоря может быть везде различной
источник

DB

Dmytro Bardai in var chat = new Chat();
Vova Lantsov
https://m.habr.com/ru/post/201874/comments/ читаем это, затем комменты, и делаем выводы) всё равно с аргументами здесь никто никого не переубедит сегодня
Хм, прочитал. Какие выводы? Мультипарадигменный подход - более лучше. Ок. Я не против. Но как это поможет мне решить конкретный пример выше?
источник

DB

Dmytro Bardai in var chat = new Chat();
Yurii Nskyi
Погнали:
1. За аутентификацию у тебя отвечает специальный сервис, который принимает на вход пользователя, тут идём вровень, НО этот сервис принимает не какую-то там ДТО пользователя, а твоего доменного, который уже сугубо правильный с точки соблюдения всех валидаций! ДТО тебе не могут гарантировать инкапсуляцию. await user.LogOn(login, password); -> бред, у тебя пользователи сами себя логинят? это же не так, даже по элементарной логике
ОК, сейчас. Спасибо за предметность.
источник

YN

Yurii Nskyi in var chat = new Chat();
Dmytro Bardai
ОК, сейчас. Спасибо за предметность.
пожалуйста)
источник

N

Name => "Kyryll"; in var chat = new Chat();
Кто тут не может процедурньій от функционального стиля отличить?
источник

DB

Dmytro Bardai in var chat = new Chat();
Yurii Nskyi
Погнали:
1. За аутентификацию у тебя отвечает специальный сервис, который принимает на вход пользователя, тут идём вровень, НО этот сервис принимает не какую-то там ДТО пользователя, а твоего доменного, который уже сугубо правильный с точки соблюдения всех валидаций! ДТО тебе не могут гарантировать инкапсуляцию. await user.LogOn(login, password); -> бред, у тебя пользователи сами себя логинят? это же не так, даже по элементарной логике
Хорошо. Только, наверно, не пользователя, а его credentials?
Как-то так?
источник

DB

Dmytro Bardai in var chat = new Chat();
источник

DB

Dmytro Bardai in var chat = new Chat();
источник

YN

Yurii Nskyi in var chat = new Chat();
Dmytro Bardai
Хорошо. Только, наверно, не пользователя, а его credentials?
Как-то так?
ну тут вариантов много, можно поделить, на AnonymousUser & AuthenticatedUser
источник

DB

Dmytro Bardai in var chat = new Chat();
Понятно, что сервис может обратиться к базе.
источник

DB

Dmytro Bardai in var chat = new Chat();
Yurii Nskyi
ну тут вариантов много, можно поделить, на AnonymousUser & AuthenticatedUser
То есть, создавать экземпляр пользователя, передавая в конструктор ничего, либо логин и пароль? Или сделать базовый класс пользователя. А потом наследников?
Приложение корпоративное, с неаутентифицированными пользователями не работает.
источник

DB

Dmytro Bardai in var chat = new Chat();
Так что, думаю, можно сделать вариант с передачей логина и пароля.
источник

ІД

Іван Данилевич in var chat = new Chat();
хтось може пояснити у чому проблема?
источник

DB

Dmytro Bardai in var chat = new Chat();
Іван Данилевич
хтось може пояснити у чому проблема?
Судя по тексту, ты собираешься удалить сущность, которая ещё не сохранена
источник