DB
а для разной реализации есть виртуальные методы, опана
О... Не может быть. Ну давай попробуем. Всё-таки создаём базовый класс? Или несколько интерфейсов?
Size: a a a
2020 April 12
G
думай федя, ты же решил доказать что ооп не нужно %)
DB
думай федя, ты же решил доказать что ооп не нужно %)
Не приписывай мне то, что я не говорил. Я предложил рассмотреть на конкретных примерах, как может выглядеть реализация задачи, когда класс с данными содержит и логику работы с ними.
Есть что сказать по существу?
Есть что сказать по существу?
G
есть, пока что ты забыл про две основных парадигмы ооп и сделал вывод что ооп не катит
G
ладно, про обосрался не буду писать, хотя очень хотелось
DB
ладно, про обосрался не буду писать, хотя очень хотелось
Не стесняйся, пиши, мне интересно
G
да я все написал уже чо хотел
DB
Что, как не аргументированная критика, помогает нам стать лучше?
DB
да я все написал уже чо хотел
Ясно-понятно. Будут предметные замечания - приходите
G
так ты еще на старые не ответил
DB
так ты еще на старые не ответил
Вопрос про виртуальные всё ещё открыт. Базовый класс или интерфейсы? Вместо ответа - съезд на парадигмы ООП. Ты так и продолжишь беспредметно отвечать?
G
так вроде ты же доказываешь что-то, почему отвечать должен я?
G
докажи что любой ответ только усугубляет ооп и надо его выкинуть
AK
докажи что любой ответ только усугубляет ооп и надо его выкинуть
так не делается в приличном обществе )
G
в приличном обществе жентельмены верят на слово
DB
Засчитан
AK
в приличном обществе жентельмены верят на слово
это уже в культурном )
VL
Супер полезно... А можно теперь предметно? Что из перечисленного выше имеет право на жизнь? А где dto+service - рулят?
https://m.habr.com/ru/post/201874/comments/ читаем это, затем комменты, и делаем выводы) всё равно с аргументами здесь никто никого не переубедит сегодня
YN
Ну вот отличный вопрос на порассуждать в воскресенье. На примере, например.
Вот у меня есть пользователь. И мне нужно его аутентифицировать.
Как оно сейчас? Сервис аутентификации, метод 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")
Так получается?
Вот у меня есть пользователь. И мне нужно его аутентифицировать.
Как оно сейчас? Сервис аутентификации, метод 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")
Так получается?
Погнали:
1. За аутентификацию у тебя отвечает специальный сервис, который принимает на вход пользователя, тут идём вровень, НО этот сервис принимает не какую-то там ДТО пользователя, а твоего доменного, который уже сугубо правильный с точки соблюдения всех валидаций! ДТО тебе не могут гарантировать инкапсуляцию. await user.LogOn(login, password); -> бред, у тебя пользователи сами себя логинят? это же не так, даже по элементарной логике
1. За аутентификацию у тебя отвечает специальный сервис, который принимает на вход пользователя, тут идём вровень, НО этот сервис принимает не какую-то там ДТО пользователя, а твоего доменного, который уже сугубо правильный с точки соблюдения всех валидаций! ДТО тебе не могут гарантировать инкапсуляцию. await user.LogOn(login, password); -> бред, у тебя пользователи сами себя логинят? это же не так, даже по элементарной логике
N