Дело в том, что мне не нужно создавать саму бд,

нужно реализовать лишь sql-запросы для тестов от компании. Их кладу в /models/, я правильно понял?

А, не. Создайте просто папку типа "database" или "repository" или типа того, там создаете структуру типа такой: https://i.imgur.com/WyAaugH.png (скрин) И после эту структуру передаете куда надо и вызываете её методы (которые внутри уже sql запрос содержат) куда хотите

А как у вас там интерфейс назван? Интересно

https://i.imgur.com/UF7mvSD.png вы только скажите и я ради вас переименую, мне не трудно))

и group и userperm и даже userrole interface soup

Спасибо) Да не, просто любопытно стало

Кидай скрин, покажи, как надо :) Зря что ли видосы твои смотрю иногда

UserStorage https://i.imgur.com/DOZapbz.png TopicStorage https://i.imgur.com/qvrqBSh.png там есть проблемы с LanguageID, но это потому что приложение мультиязычное на уровне БД. на этапе MVP дико впадлу что-то с этим делать, оставил как есть а про видосы, ты главное лайк ставь и комментарий пиши )))

"на этапе MVP дико впадлу что-то с этим делать, оставил как есть" - на скрине моем как раз mpv :)

на скрине антипаттерн, а не костыль )

Ну смотри, у меня у группы может быть список ролей, и у пользователей в этой группе могут быть свои роли. Как бы ты назвал метод который добавляет роль пользователю в группе ?

А вот на втором скрине в методе Create используется dto CreateTopicDto А как вы этот метод выглядит в реализации?

https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D1%82%D0%B8%D0%BF%D0%B0%D1%82%D1%82%D0%B5%D1%80%D0%BD Каша из интерфейсов (interface soup)

transport (HTTP) --DTO—> service --DTO—> storage последствия луковой архитектуры

так...что-то я все равно не догнал, где у меня каша и костыль :( Я кажется, понял. Ты решил, что методы интерфейса у меня интферфейсы принимают?

Не знаю, чего это последствия, но так не должно быть. А если вам в другом месте понадобится тоже вызвать метод из DB на создание topic? Ваш CreateUserDto то в конкретном пакете лежит

методы для разных доменных сущностей в одном интерфейсе

он лежит в пакете db, так что никаких проблем нет но так быть не должно, это я уже привык к этой фразе в этом чате (без пруфов офк)

Он - это кто?

класс createtopicdto

имеешь ввиду, что у меня в интерфейе для групп есть метод который принимает UserRole?

красным я подчеркнул разные сущности https://i.imgur.com/PIblwA3.png

Эта структура лежит в пакете topic, вы же к ней как topic.CreateUserDto обращаетесь

да наверху импорт надо переименовать. create dto лежит в topic.db

понял о чем ты, но менять не буду :)

а я и не настаиваю )

Вот вообще уже все непонятно стало, где что лежит, и что к чему обращается

да согласен, ужас еще раз transport (HTTP) --DTO—> service --DTO—> storage данные из слоя в слой переходят через DTO своего слоя - последствия луковой архитектуры я это в самом первом сообщении написал добавить нечего

Мне эти стрелки не о чем не говорят, потому что они не указывают, что в каком пакете лежит, и как между собой разные слои взаимодействуют. Задам вопрос по другому: У вас есть service, он лежит в каком-то пакете у вас есть storage он лежит в другом пакете В сервисе есть интерфейс, который описывает работу со storage с использованием dto Где лежат dto? В пакете сервиса, стораджа или в неком третьем пакете?

в транспорте свои DTO в сторадже свои DTO маппинг serviceDTO в storageDTO происходит в слое сервиса

перекрывают ли плюсы накладные расходы в виде копирования структур туда-сюда? Плюс помимо обычных данных там могут быть и слайсы/мапы

иногда да иногда нет. зависит от приложения и предметной области

То есть, пакет сервиса обращается к topicdb.CreateTopicDto? Где topicdb - это пакет, где реализован методы storage

Мне кажется что маппинг в сторадже всетаки происходит. В сервисе storageDTO не нужен

функцию NewGroupService, к-я создает объект GroupService, вы где вызываете, в repository?

Нет, я использую следующую структуру (упрощенно): ---> api (хендлеры, куда приходит запрос, тут проверка аутентификации, парсинг json и валидация того что пришло) ---> service (логика, проверка прав доступа, и перед созданием пользователя, я заполняю дату создания и присваиваю стандартную "роль", а после успешного создания - направляю письмо на почту) уровень service вполне может делиться на два (например некий слой сценариев, который уже оперирует сервисами) ---> repository (бд, тут просто выполняется sql запрос в бд)

MVT

расширил ответ

в методах хендлера в "ресивере" объект содержит service?

Да, либо интерфейс с методами этого сервиса

например, в main вызвал "функцию-конструктор" для service и передал метод "хендлер". В "хендлере" же тоже нужно создавать объект, но теперь уже для "service". Вот где в "хендлере" вызвать "функцию-конструктор" для service, в поле самой структуры?