Как организовать архитектуру кода для взаимодействия с БД в Golang?

Question

[NameOf Var]

Всем привет! Недавно решил для себя открыть новый язык программирование и перешёл на Golang после .NET (C#)
Не хочется быть тем, кто пытается сделать шарпы из Golang, поэтому есть пара вопросов по организации кода на Go, т.к. подход разработки сильно отличается то подходов в Дотнете.

1. В шарпах очень распространен паттерн Repository/Unit Of Work. Несмотря на многие споры вокруг целесообразности применения этих паттернов, они довольно удобны в применении за счёт развитых инструментов dependency injection, которые идут из коробки в ASP.NET. Однако, я не заметил практики использования репозиторией в Go (как и в целом подхода с dependency injection). Стоит ли писать подобные репозитории в своем коде на Go или есть какие-либо альтернативные паттерны для изоляции слоя баз данных и бизнес-логики? Буду очень признателен, если скинете примеры реализации.

2. Часто замечаю, что очень редко отдается предпочтения в сторону ORM-решения и все запросы пишутся вручную, несмотря на то, что существует изобилие различных библиотечек для Go (https://github.com/avelino/awesome-go#database - есть даже аналог Entity Framework в мире Go). Связано ли это с попыткой максимально оптимизировать код приложения или просто нет достойных ORMок для Golang?

3. В связи с редким использованием ORM, применяются ли какие-либо решения для запуска скриптов миграции?

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

Comments

[alfss]

Просто оставлю это тут https://github.com/alfssobsd/clean-arch-golang-bes...

https://github.com/go-pg/pg
https://github.com/go-pg/migrations
https://github.com/dizzyfool/genna

Answer 1

[DollyPapper]

Тут все зависит от того как вам удобно, кто бы что не говорил, нет единого стандарта нужно/не нужно. Я наоборот чаще вижу что вместо прямого источника данных подают репозитории в сервисы. И сам так делаю. Это банально удобней тестировать.

Answer 2

[12rbah]

паттерн Repository/Unit Of Work.

Честно говоря это не очень популярно из-за того, что изолировать при помощи интерфейса не всегда нужно, часто структуры будет достаточно, в которой есть подключение к бд и поле для данных. Есть такой пример. Если у вас планируется несколько источников данных, то возможно вам будет удобнее делать на интерфейсах, но by design интерфейс обычно содержит 1-2 метода, а городить на каждую структуру интерфейс с 5-7 методами немного странное решение для го(с моей точки зрения), чтобы лучше понять го можно прочитать книгу кернигана и книгу 100 go mistakes(примерно так называется), чтобы получше понять суть языка.

просто нет достойных ORMок для Golang

Более приемлимым вариантов считается использование sql билдеров или генерация запросов, честно говоря к этому спорное отношение и где-то вполне себе используют орм.