@hax
junior developer

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

Всем привет! Недавно решил для себя открыть новый язык программирование и перешёл на 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-приложения с хорошей архитектурой кода взаимодействия с базой данных.
  • Вопрос задан
  • 511 просмотров
Пригласить эксперта
Ответы на вопрос 2
DollyPapper
@DollyPapper
Тут все зависит от того как вам удобно, кто бы что не говорил, нет единого стандарта нужно/не нужно. Я наоборот чаще вижу что вместо прямого источника данных подают репозитории в сервисы. И сам так делаю. Это банально удобней тестировать.
Ответ написан
Комментировать
@12rbah
паттерн Repository/Unit Of Work.
Честно говоря это не очень популярно из-за того, что изолировать при помощи интерфейса не всегда нужно, часто структуры будет достаточно, в которой есть подключение к бд и поле для данных. Есть такой пример. Если у вас планируется несколько источников данных, то возможно вам будет удобнее делать на интерфейсах, но by design интерфейс обычно содержит 1-2 метода, а городить на каждую структуру интерфейс с 5-7 методами немного странное решение для го(с моей точки зрения), чтобы лучше понять го можно прочитать книгу кернигана и книгу 100 go mistakes(примерно так называется), чтобы получше понять суть языка.
просто нет достойных ORMок для Golang
Более приемлимым вариантов считается использование sql билдеров или генерация запросов, честно говоря к этому спорное отношение и где-то вполне себе используют орм.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы