Комментарии 4
Разрабатывая переносимый между платформами и БД код на Perl, C++ и Java cтолкнулся в Go с «database/sql» так больно мне не было давно… Начиная от компляции Ораклового драйвера в проект когда без работающей среды gcc не сделаешь ни чего. А мучение и боль при необходимости переключиться с MySQL на Oracle и обратно превращается в какой то ад. притом что в коде на Perl ни чего не меняется, даже в гребной Java практически ни чего (Да буде жить вечно JDBC!) ну ладно в C-x пару десятков строк. А Go… Даже не хочется начинать новые проекты на нем. Go это к сожалению не энтрпрайз и не понятно когда там все наладится. От кода:
tx, err := m.DB.Begin()
if err != nil {
return err
}
Хочется стреляться.
tx, err := m.DB.Begin()
if err != nil {
return err
}
Хочется стреляться.
0
Хочется сказать, что Go никогда и не был нацелен на «Enterprise» :). Этот язык создавал Google для решения своих задач прежде всего, и по-моему, задачу написания высококонкурентных сетевых сервисов он помогает решать очень хорошо :). А драйвер для Oracle под Go наверняка уже переписали на чистый Go, хотя я не смотрел, если честно.
0
Вопрос к автору статьи: можно в двух словах основной посыл. Вроде должно быть полезно, но я мало чего понял.
Скажем, зачем вы добавляете функцию в структуру а потом ещё и меняете сигнатуру, почему не написать отдельную функцию для чего угодно и просто вызывать при необходимости? Функция в структуре не очень смотрится, как по мне.
Вы рекламируете свой пакет вместо стандартного, в чём его преимущество?
Скажем, зачем вы добавляете функцию в структуру а потом ещё и меняете сигнатуру, почему не написать отдельную функцию для чего угодно и просто вызывать при необходимости? Функция в структуре не очень смотрится, как по мне.
Вы рекламируете свой пакет вместо стандартного, в чём его преимущество?
+1
Статья описывает более гибкий и более устойчивый к изменениям стиль программирования с базами данных для комплексных систем взаимодействия с базами данных. Статья построена на отдельно взятом примере вынужденного изменения сигнатуры события OnSignup (старый стиль) при эволюции менеджера, взаимодействующего с базой данных. Событие же OnSignup здесь реализовано в виде простой функции, хотя в реальной жизни, оно будет реализовано в виде механизма издатель/подписчик.
На первом шаге эволюции мы получаем сигнатуру события не зависящую от области видимости базы данных (это может быть, как база данных, так и транзакция). Такой стиль уже сам по себе является достаточно универсальным, поскольку сигнатура события уже не подвержена изменениям.
На втором шаге эволюции, поместив область видимости в контекст, мы приходим к семантически стандартному виду интерфейса, однако, за кулисами остается все та же универсальная область видимости.
Автор вынужден был использовать внешний пакет (который является оберткой вокруг стандартного пакета database/sql), поскольку под капотом достаточно много кода, которым не хотелось бы перегружать статью.
На первом шаге эволюции мы получаем сигнатуру события не зависящую от области видимости базы данных (это может быть, как база данных, так и транзакция). Такой стиль уже сам по себе является достаточно универсальным, поскольку сигнатура события уже не подвержена изменениям.
На втором шаге эволюции, поместив область видимости в контекст, мы приходим к семантически стандартному виду интерфейса, однако, за кулисами остается все та же универсальная область видимости.
Автор вынужден был использовать внешний пакет (который является оберткой вокруг стандартного пакета database/sql), поскольку под капотом достаточно много кода, которым не хотелось бы перегружать статью.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Golang и эволюция взаимодействия с базами данных