"взять данные и положить в базу"

логика - ничто, архитектура - всё

а если там не особо много логики?

значит просто структура без ничего

просто может возникнуть непонятное желание впоследствии эту логику впихнуть

тоесть можно сделать два пакета аля dbAdapter и db где - UserModel.go - AnyModel.go

и вот на этом этапе тебе будет больно, если сейчас ты не разделишь модель и бд-лейер

в dbAdapter тем не менее получается есть пару функций которые принимают на вход модель

кстати, по опыту, тупо описание структур, как правило, удобнее в отдельном модуле хранить

аля SaveUser()

смотри, чо скажу:

1. отдельный пекедж с описанием структур

2. пекедж-адаптер для БД, который импортирует пекедж №1.

3. пекедж с бизнес-логикой, который импортирует пекедж №1.

и все это потому, что циклические зависимости нельзя

и всё у тебя будет хорошо, я в тебя верю)

так

а бизнес логика же должна взаимодействовать с адаптером бд как то?

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

а бизнес логика же должна взаимодействовать с адаптером бд как то?

а вот не факт, например

а если должна, то, вероятно, через интерфейсы

это если ты хочешь именно слои друг от друга отпилить

т.е. если ты не хочешь, чтобы бизнес-логика зависела от слоя БД, то ты должен импортировать интерфейсы

Отдельные структуры: - Яблоки - Апельсины Адаптер - Поискать яблоки на дереве - Поискать апельсины на дереве - Новый апельсин - Новое яблоко - Сохранить апельсин - Сохранить яблоко Бизнес логика - Если яблоки зеленые то не сажаем на дерево

что-то в этом духе?

собственно, у тебя два пути: DAO либо репозиторий

собственно, они похожи, причем сильно, вплоть до взаимопроникновения, хотя есть нюансы, доступные избранным (не всегда и не во всем мне)

итого у тебя есть пакадж models

внутрях: type Apple struct type Orange struct

на этом твои модели, фактически, заканчиваются

туда же ты можешь вкрутить обвязку по яблокам/апельсинам, которая зависит конкретно от полученного яблока/апельсина и не требует записи в базу

типа func (a *Apple) Color() string { return a.Color }

а дальше у тебя отдельный пакадж, допустим, dao

там методы соединения с базой и т.д. и т.п. - вся эта мишура

и плюсом, условно, тупой CRUD

но DAO пакет получается должны тоже импортировать модели

т.е. func (dao *DAO) CreateApple() (*Apple, error) func (dao *DAO) ReadApple(appleID int64) (*Apple, error) func (dao *DAO) UpdateApple(apple *Apple) error func (dao *DAO) DeleteApple(alleID int64) error

и более того, знать про них

вот dao и импортирует models

весь смысл именно в том, что models твой - основополагающая сущность

чем в итоге dao от. репозитория отличается?

от него пляшет вся остальная бизнес-логика

DAO будет неконтролируемо расти тогда

пухнуть от каждой модели

чем в итоге dao от. репозитория отличается?

насколько я в курсе, тем, кто владелец объекта

пухнуть от каждой модели

не совсем, собственно

но близко к правде

там дальше уже финты ушами на тему:

1. универсальные CRUD-методы

т.е. Create(item interface{}) error

и в таком роде

а вот это не надо! :)

это потянет рефлексию

либо раздельные дао на каждый тип item'а

т.е. type AppleDAO struct, type OrangeDAO struct

весь смысл этой хрени в том, что сама структура Apple|Orange тебе может понадобиться везде, а dao - только в тех местах, куда надо сохранить

я бы тогда AppleDAO положил бы в пакет рядом Apple

вероятна еще такая штука: type AppleDAO struct { item *Apple } func NewAppleDAO() *AppleDAO, err {} func (a *AppleDAO) GetApple() *Apple { return a.item }

я бы тогда AppleDAO положил бы в пакет рядом Apple

а вот тут и косяк

в одном пакете их класть не надо

в соседний - без вопросов

по поводу дао выше - а как же мульти яблоки? поиск всякий

просто, допустим, если ты потом будешь писать тупенький декоратор вида package colordecorator improt ".../models" func RuColorOfApple(apple *models.Apple) string { switch apple.Color { case "Red": return "Красное" } return "Непонятный какой-то цвет" } ты в зависимостях тупого декоратора за собой БД притянешь

т.е. описание структуры/модели - отдельный пакадж, работа с БД - отдельный

не логично ли было этот декоратор положить в модели тогда

1. откуда тяга класть все в модель 2. а куда класть декоратор вида func RuColor(item FruitColored) string {} при условии, что type FruitColored interface { Color() string }?

ты, конечно, на входе сэкономишь на количестве пакаджей, но на выходе такого геморроя можешь хлебнуть с композицией

собственно, если у тебя что-то на пару структур и 3 метода работы с базой, при этом оно "разовое" и "дальше мы ничего с этим делать не будем" - нивапрос, сложи все в кучу, и не заморачивайся. Работать оно будет, да и на таких случаях это действительно ПРАВИЛЬНАЯ архитектура.

ERROR: S client not available

пилить 200 строчек кода на 4 пакаджа - это таки перебор

ну ясен хрен что 200 перебор

а по поводу дао, как с коннектом бд быть там?

но если ты планируешь именно что-то "наращивать" сверху - то тебе придется это делать

прокинуть "чистый" коннект в хедлер и потом кормить им дао в фабрику или же как то заморочиться

а по поводу дао, как с коннектом бд быть там?

type DAO struct { dbConn *sql.DB .... }

собственно, можешь даже синглтон заюзать для БД

а потом в контроллер получается NewAppleDAO(c.DBConn)

просто sql.DB - это пулл коннектов

а потом в контроллер получается NewAppleDAO(c.DBConn)

ну да

у меня не совсем реляционная бд там...

но это подробности

ну да

еще есть нюансик там

а дао привязан к реализации конкретной бд?

если мы сменим Mysql на Postgre (условно), менять придется все дао + вызовы контролера

ладно в любом случаи спасибо за консультацию

а дао привязан к реализации конкретной бд?

это от реализации зависит

ты ПОД дао можешь подложить интерфейс с вызовами к БД

а потом реализовывать интерфейс уже в конкретных модулях для каждой БД свой

да я уже тут нашел такое вот - https://github.com/gustavocd/dao-pattern-in-go

собственно, по поводу "гибкости" и "мультияблок", если честно, Go не лучший выбор

гибкость и мультияблоки, а также особо ветвистая бизнес-логика + классические паттерны и мощная система типов - это немного НЕ про Go, это скорее в сторону Java или C#

в гоше дженериков нет

когда я говорил про мультияблоки, я имел введу возможность возвратить не 1 яблоко, а несколько

про слайс яблок

ну, фактически, для гоши, у тебя 2 варианта, опять же

я как понял это можно запулить в яблочные ДАО метод search и там вернуть []*Apple

либо Read(someParams *requestParams) []*Apple {}

и это для всех

просто когда ты выбираешь 1 яблоко, у тебя будет возвращаться слайс из 1 яблока

либо 2 метода

это да