Статья написана, как ответ на опубликованную ранее статью-антипод.

На протяжении последних двух с лишним лет использую Go для реализации специализированного RADIUS сервера с развитой биллинговой системой. По ходу изучаю тонкости самого языка. Программы по себе очень просты и не являются целью написания статьи, но сам опыт использования Go заслуживает того, чтобы сказать пару слов в его защиту. Go становится все более массовым языком для серьезного масштабируемого кода. Язык создан в Google, в котором им активно пользуются. Подведя черту, я искренне считаю, что дизайн языка Go плох для НЕумных программистов.

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

С момента появления паттернов проектирования появляются все новые примеры их эффективного использования. И это замечательно. Однако, здесь не обошлось и без ложки дегтя: каждый язык имеет свою специфику. А уж golang — и подавно (в нем нет даже классической модели ООП). Поэтому и возникают вариации шаблонов, применительно к отдельно взятым языкам программирования. В этой статье хотелось бы затронуть тему паттернов проектироавния применительно к golang.

В этой статье хочу обобщить проблемы работы с базами данных под управлением golang. При решении простых задач обычно эти проблемы не видны. С ростом проекта масштабируются и проблемы. Наиболее злободневные из них:

• Снижение связности приложения, работающего с базой данных
• Журналирование запросов в отладочном режиме
• Работа с репликами

Статья построена на основании пакета github.com/adverax/echo/database/sql. Семантика использования этого пакета максимально приближена к стандартному пакету database/sql, поэтому не думаю, что при его использовании у кого-нибудь возникнут проблемы.