Если ты не в состоянии описать пользу отабстракции в нескольких словах на понятном языке , значит либо пользы нет, либо ты абстракцию не понимаешь
угомонись уже. В тебе дружно признали крутого архитектора. Довольно
Maksim
Daniel
Если ты не в состоянии описать пользу отабстракции в нескольких словах на понятном языке , значит либо пользы нет, либо ты абстракцию не понимаешь
Это правда, но давайте снизим градус
L
Окей, ну вот все скрываем значит за методом Get/Create
Хочу тестировать отдельно кэш и работу с бд, а потом еще и связку
V
Если ты не в состоянии описать пользу отабстракции в нескольких словах на понятном языке , значит либо пользы нет, либо ты абстракцию не понимаешь
вам уже все описали несколько раз, причем часть кейсов вы наммеренно попросили опустить и не описывать, хотя они тоже реальны
Алексей
Если ты не в состоянии описать пользу отабстракции в нескольких словах на понятном языке , значит либо пользы нет, либо ты абстракцию не понимаешь
Простите, Pawel, я уже описал, а то что моё описание для вас непонятно - это уже боюсь не моя вина.
Maksim
в чём плюсы миллион раз описали. Если человек на столько крут, что понять этого не в силах, это проблема человека и перекладывать её на других - по меньшей мере глупо.
Aleksandr
Нас в принципе не волнует откуда и как оно получает
хорошо. ты с некоторыми оговорками описал репозиторий
L
Ну, вот тут возможно проблема
Вот, польза репозитория как раз в том, что бы абстрагировать работу с данными (условно get/set) от конкретной реализации этой работы (redis-get, redis-set)
Maksim
Странно, реализации то вроде как разные
ты просто разделил запись и чтение, которое почему-то проигнорировал
Aleksandr
Странно, реализации то вроде как разные
оговорка в том, что не сущность сама себя сохраняет и сама себя из хранилища получает
L
Ну, вот тут возможно проблема
а имея унифицированный интерфейс, ты сможешь в своем коде прокидывать разные реализации интерфеса и не придется ничего переписывать (зачастую)
.
Я вот часто видел что в структуру репозитория пихают бд. Верно?
Maksim
чтением у тебя в примере занимается репозиторий, а запись почему-то ответственность сущности.
Pawel
Это правда, но давайте снизим градус
Заметьте, я не плююсь и не даю ни кому оценок в отличие от. Просто интересно как они это пытаются объяснить.это смешно же
Алексей
Заметьте, я не плююсь и не даю ни кому оценок в отличие от. Просто интересно как они это пытаются объяснить.это смешно же
Обычно я тоже стараюсь не давать оценок. Но тут уж не сдержался, слишком вопиющий случай.
.
Допустим транзакция вида: создаём сообщение, обновляем счетчик сообщений.
.
Как это будет организовано через репозитории?
Maksim
в репозитории просто этого быть не должно)
.
Не должно быть чего? Транзакций?
Maksim
ровно как и создания чего-либо
L
Как это будет организовано через репозитории?
например композиция репозиториев с подержкой транзакций между ними
Artem
А почему создавать две? Почему мы не можем определить всю эту логику внутри метода получения Юзера?
потому что код пишут много людей и требуется проводить границы между командами
одни могут заниматься логикой - взаимодейтсвием пользователей друг с другом
другие - сохранением даных
чтобы не видеть файл user.go на 5к строк в котором будет перемешано и работа с БД и с кешем и запросы в third-party и логика приложения и используют абстракции
Maksim
там выше накидывали за cqrs. очень в цвет накидывали
Artem
если есть проблемы с данными - ты ищешь их в коде репозитория
Artem
если есть проблемы с логикой - в других частях приложения
Maksim
там выше накидывали за cqrs. очень в цвет накидывали
cqrs - архитектурный паттерн, который позволяет разделить чтение и запись. Жить станет чуточку проще, ровно как и код организовывать.
Artem
cqrs - архитектурный паттерн, который позволяет разделить чтение и запись. Жить станет чуточку проще, ровно как и код организовывать.
с cqrs жить становится сложнее, это больше вынужденная мера
Maksim
с cqrs жить становится сложнее, это больше вынужденная мера
Только когда начинаешь втягиваться, как и с любым подходом.
Artem
на определенном этапе развития приложения, когда за его работой становится сложнее следить, требуется применение более сложных подходов, которые обеспечат распределение нагрузки на людей (а так же рост самой команды)
Artem
но это никак не упрощает саму разработку
Artem
и поддержку
Maksim
как cqrs относится к тому, что ты написал?
Artem
как и применение репозитория, о котором тут срались выше
Artem
он тоже усложняет код
Maksim
блин... вы тут на наркоте что ли сидите
Bohdan
ну он-то усложняет, да
но я лично не хочу писать в процедурном стиле даже на простейших проектах
Artem
Репозиторий усложняет код а?
если у меня api из трех методов в 30 строк кода в каждом - зачем мне абстрагироваться от хранилища?
V
обработка ошибок усложняет код
L
если у меня api из трех методов в 30 строк кода в каждом - зачем мне абстрагироваться от хранилища?
сегодня их три, завтра их 33
Artem
рефакториг никто не отменял
V
нет, правда, гораздо проще же везде делать panic(err), а в мейне один обработчик паники 🙂
Pawel
нет, правда, гораздо проще же везде делать panic(err), а в мейне один обработчик паники 🙂
Обработчик паники в мэйне бесполезен. Учите го ))
Bohdan
если у меня api из трех методов в 30 строк кода в каждом - зачем мне абстрагироваться от хранилища?
если тебе придется что-то в нем менять - то будет полезно
V
спасибо за ценный совет, пора мне перестать пукать в этом чате
.
Кстати, такой вопрос по логированию: я так понимаю что хоший подход инициализировать БД, логгер и прочее в мейне и потом пробрасывать это все через уровни. Вот мы на уровне бизнес логики, и у нас идёт обращение к БД через какой то метод. Где мы должны логировать – на уровне обращения к БД либо на уровне бизнес логики ?
.
Заранее извиняюсь если сумбурно
Pawel
Более того, панику вообще не надо обрабатывать. Любителям репозиториев на заметку
L
V
вы видите те же слова, что и я?
Maksim
Кстати, такой вопрос по логированию: я так понимаю что хоший подход инициализировать БД, логгер и прочее в мейне и потом пробрасывать это все через уровни. Вот мы на уровне бизнес логики, и у нас идёт обращение к БД через какой то метод. Где мы должны логировать – на уровне обращения к БД либо на уровне бизнес логики ?
бизнесс логика ничего не знает про базу и логгер. Это инфраструктура
Maksim
отвечая на твой вопрос, запросы будут логироваться там, где работа непосредственно с хранилищем
.
бизнесс логика ничего не знает про базу и логгер. Это инфраструктура
Ну вы ведь явно пробросите их как параметры. Либо же объявите на цровне пакетов?
Maksim
что и куда я проброшу? я не буду в доменный слой пробрасывать коннект к бд и логгер. нефиг им там делать
.
Окей. Тогда какой подход выберете вы?
Maksim
не буду этого делать, очевидно.
я вопрос твой понять не могу.
V
чем плох логгер в бизнес-логике? 0о
V
тем, что он не используется в бизнес-логике и там не нужен
Maksim
тот же ответ и логгеру
V
но ведь в бизнес-логике требуется логирование
.
Так где Логировать?
Maksim
бизнесс логике логирование зачем? приведи пример
V
не запросов к базе, но вещей связанных с бизнес-логикой