Comments 34
Дайте угадаю, Go не первый язык, а до него был C#? DI — это антипаттерн, ORM — тоже. GORM — два антипаттерна.
Являются ли DI и ORM антипаттернами в конкретных проектах, зависит от того, что предлагаете использовать взамен и в каких проектах.
В таком DI слишком много завязано на магии и interface{}, что совсем не есть хорошо. Типобезопасности ноль. Если уж так хочется использовать DI, то лучше использовать что-то с кодогенерацией (и нормальными типами) и Intejection в Compile-time, например https://github.com/google/wire
Посматривал на Wire, но после опыта с Dig взял вариант попроще. Но раз советуете, посмотрю на Wire внимательнее.
DI — это антипаттерн
Не надо быть настолько категоричным. Не все реализации DI — антипаттерны.
DI можно сделать без фреймворков явно через конструкторы, с честным composition root
Я понимаю, что автор, и большинство комментирующих, включая меня, имели ввиду не сам DI, а именно DI container. Они зачастую ходят парой, и люди, говоря DI, часто подразумевают именно DI container.
В Go обычно используется именно подход с ручным внедрением зависимостей при создании структур, а DI Container считается антипаттерном.
Сервис-контейнеры тоже можно использовать по разному.
Одно дело, в коде приложения получать экземпляры из контейнера. Тогда ломается идея статической типизации, да и в коде бизнес-логики начинает светиться эта архитектурная подробность.
Другое дело, всю инициализацию прятать в описании сервис-контейнера и необходимые экземпляры прокидывать в конструкторы. Тогда получение экземпляров из контейнера будет только в роутере, и риск получить проблемы в рантайме очень мал.
Непонятен выбор govendor, в то время как после него уже вышли более удобные и поддерживаемые альтернативы, ставшие стандартом де-факто:
1) dep — официальный эксперимент, который все ещё поддерживается (однако, поддержку новых версионных импортов не завезли, многие новые библиотеки с мажорной версией >1 загрузить через него, как и через более старые инструменты, вообще нельзя)
2) go modules (официальный инструмент в комплекте go 1.11+), позволяет в том числе и вендорить зависимости.
Использование go-modules — задел на будущее
Пока смотрел сторонние библиотеки, обратил внимание, что почти во всех есть go.mod. Но вот попробовал использовать go modules и столкнулся с тем, что возникают проблемы при выборе версий пакетов
В качестве замены makefile в го проектах, можно использовать Gilbert — github.com/go-gilbert/gilbert
Теперь ждем от тебя статью, как ты быстро отказался от всего этого и начал уже программировать на Go.
Советую посмотреть ozzo-{что-то}. Это независимые библиотеки от создателя Yii-фреймворка на PHP.
Мы используем его:
- Логер, он реально крут, по моему мнения вне конкуренции на данный момент.
- Валидацию, все просто, удобно и хорошо группируются ошибки.
- Роутер, на самом деле используем не на 100%, он, не понимаю почему, построен по аналогии с express.js и другими подобными решениями под node.js с передачей запросов по цепочке обработчиков, что на самом деле не имеет смысла в Го, так как есть нормальный стек вызовов. Не используем его обработчик ошибок.
На счёт DI, не знаю с каких пор он стал анти-паттерном? Вот IoC реализовать в Go я бы не решился. Может я что-то не правильно понимаю, но IoC — это когда контейнер сам управляет приложением и мы просто даём знать объект какого интерфейса нам нужен, а в DI мы можем и сами взять из контейнера зависимости.
Может я путаюсь в этих терминах, но мы тоже решили оставить набрать типизацию, по возможности без всяких interface {}. Просто есть пакет container, которой создаёт все нужные зависимости уровня приложения, типа соединения с БД или логом, а потом в приложении каждый тип достает из контейнера то, что ему нужно.
Спасибо Вселенной, что я не участвую в подобных проектах:
— govendor
— Gin (он норм, вот только из-за его няшности возникают проблемы с зависимостями, прям удивительно, тащить фреймворк и страдать от его топорности. люди иммутабельны)
— DI в рантайме
— толстые CRUD-интерфейсы
— Viper для вязкости конфига
— logrus… не буду много говорить, потому что сильное имхо, пусть буит
— лол втф «для юнит-тестов пришлось выделить отдельный пакет. <..> библиотека для создания сервис контейнера не позволяла переопределять сервисы»
1 коммент вместо саммари:
Теперь ждем от тебя статью, как ты быстро отказался от всего этого и начал уже программировать на Go.
аве
взято здесь -> t.me/oleg_log/1138
В PHP динамическая типизациия. Там это не очень то и нужно.
Конечно можно, и примеры есть. Docker, например. На PHP 4 без классов тоже были довольно масштабные приложения.
Я о другом. Если в PHP без генериков можно спокойно обойтись, то в Go приходится либо пользоваться рефлексией, по сути отказываясь от статической типизации, либо использовать много где interface{}, либо копипастить, либо придумывать особые реализации.
Я лет 5 на ГО пишу, и от этой статьи у меня течет кровь из глаз.
Мне время от времени встречаются разработчики, которые тоже придерживаются мнения, что надо делать "по простому". Недавно вообще попался парень, который даже composer при разработке на PHP не использует. Но по факту код таких ребят оставляет желать лучшего. А истинная причина желания писать "по простому" в нежелании поработать над собой, чтобы научиться делать технологичный код.
Это такой код где для простейшего действия применяются огромные либы в концепции чем больше в ряд их составить тем круче? :)
Не, вообще вот этот твой трепетный пыл неокрепшего ума на самом деле даже мил. Но в жизни все не так :)
Мне такое мнение понятно, я и сам лет 10 назад был приверженцем гумнокода. Но с практикой как то пришло понимание, что какой бы проект не начался, после разработки он не упрощается, а наоборот, появляются новые задачи и надо что-то дорабатывать, менять. Гораздо легче это делать, когда заложен сразу номальный подход.
Поделитесь примером, как на самом деле по вашему мнению надо проектировать код, мне не удалось найти вас на гитхабе.
Значит код показать не можете. Ок.
Тут довольно разные комментарии и комментаторы. Не удивляйтесь, но среди них есть даже такие, для которых вместо здравых суждений достаточно размышлений наподобие "пипец из либ", "сивой кабылы", "дич".
Насчет "пипца из либ" вспомнился коллега, который придерживался аналогичного мнения и стремился сделать проекты с минимум зависимостей. Если задачу не поставить максимально четко вплоть до выбора готовых либ — тратил бюджет проекта на разработку уже изобретенных велосипедов. Потом этот код еще и поддерживать приходилось, а что-то и переписывать, когда доставляло действительно много проблем. По мне лучше использовать готовое и проверенное, чем так.
Каркас API на Golang