Опять мимо. Я не против, что бы меня минусовали не только "мальчики', но и "девочки". Но только, что бы они дополнительно оставляли коммент, что бы нельзя было просто так минусовать.
Контейнер решает именно ту задачу, которая описана в предыдущей статье и которая нужна для тестов: создает под дерево зависимостей по требованию с возможностью подмены зависимости на любом уровне. Например глубина дерева зависимостей 5, можно подменить только листовые зависимости.
Никакой контейнер в go не упрощает код. Максимум делает его более структурированным. Потому что все равно придётся регистрировать все зависимости руками. Какой бы контейнер не был. Обьем пакета с зависимостями или конфигурации контейнера всегда примерно одинаков. Autowire невозможен, как в symfony.
По сути это решение НЕ контейнер в классическом его понимании. Он не хранит мета информацию о связях и т.п. Это обычный пакет который создает зависимости. Только фабричные функции там обернуты в провайдеры. Провайдеры позволяют создавать зависимости лениво. Это позволяет в тестах создавать часть дерева зависимостей, и подменять зависимости на любом уровне.
Паралельный запуск условно возможен без изменений API, если добавить правильные локи в метод Use и Mock. Нужно над этим поразмыслить.
dc.SubService.Mock(mock1)
service1 = dc.Myservice.Use()
dc.Reset()
// и тут же сделать
dc.SubService.Mock(mock2)
service2 = dc.Myservice.Use()
dc.Reset()
Здесь это будут разные инстансы одного и того же сервиса в одном тесте. Нужно решить проблему одновременного чтения и записи моков.
DI-контейнер используется не сам по себе, а как часть подхода инверсии зависимостей.
DI-контейнер не часть принципа, а инверсия зависимостей не предполагает использования контейнера. Ручное вредрение не противоречит принципу внедрения заимостей. DI-контейнер - это один из инструментов, который можно не использовать, а можно использовать.
Можно брать кувалду и забивать гвозди..., а можно молоток.
Проблема с тестами решается проще чем изучение uber-fx и затаскивание его в проект. Об этом здесь "Еще раз про Di-контейнеры в golang" https://habr.com/ru/articles/903300/
Которое невозможно ни править, ни покрывать юнит-тестами. Добавляем сверху идиотское корпоративное требование 90% покрытия юнит-тестами, и получаем огромные уродливые тесты, которые ничего, на самом деле внятно не тестируют (потому что с такой связностью практически невозможно изолировать отдельные модули и тестировать их отдельно), но при этом тесты будут неочевидно ломаться от почти любых изменений в коде.
Второй человек пишет про Юнит-тесты. Но я вот не понимаю, причем тут DI-контейнер? Тесты они ведь Юнит, потому что должны тестировать юнит без контейнера. Когда считается покрытие, то счетчику вообще пофигу используете вы DI или нет. Или у вас не так?
Вы используете DI, что бы удобно писать тесты: в тестах вы "поднимаете" весь DI, частично мокаете и потом запускаете тест. И так для каждого теста. Если в контенере 1000 сервисов, нужно замокать 1, вы его мокаете и запускаете тест. Так получается?
я непонял: для тестов у Вас есть отдельная конфигурация контейнера? в ней только нужная ветка с заглушками? или как?
Если нужен функциональный или интеграционный тест, то скорее всего вы однимите сервис целиком, как "черный ящих" и мокать нужно будет только внешние запросы в БД или другие сервисы. В остальном работают Unit-тесты. Или я что-то не понимаю? Напишие ситуацию подробнее, интересно понять.
@Vladimir_ch_dev посмотрел befree.ru. Об этом же сайте речь? Там есть полнотекстовый поиск и фасетные фильтры. можете рассказать на чем ни сделаны, если вы раньше не использовали Эластик? хотя бы в 2-х словах.
Получаем из эластика пагинированные id карточек, отвечающие условиям фильтра (запрос приведен ниже)
Задача на полнотекстовый поиск есть? Если есть, получается он не работает? Если работает, то из статьи совсем не понятно, как это происходит. 2.
Конечно мы не избавились от использования реляционной базы полностью, но вынесли за ее пределы наиболее нагруженную часть – непосредственно фильтрацию.
Выглядит так, что значения фильтров не меняются в зависимости от запроса. Т.е. фильтрация может выдать пустое множество. Тогда предстоит реализовать еще и фасетный поиск. Если нужно, то алгоритм есть здесь https://habr.com/ru/articles/517074/
Сроки - это стоимость. Вопрос в том, сколько будет стоить фича или можно это время потратить более продуктивно.
все верно, согласен. А что такое продуктивность? в чем она измеряется? Вот 2 задачи: одна 2 дня, вторая 2 недели? Как понять, какая из них получилась не продуктивно?
Я иногда спрашиваю - а зачем её делать, что бы что? И ответа нет
Проблема в том, что в диалоге нет ничего про value для пользователя и бизнеса. Ну, т.е. мы думаем о целях бизнеса, пользователя или пилим задачи, которые дешевле?
Диалог мог быть начаться так:
Ребята, мы получили (собрали) обратную связь от пользователей. Есть запрос на бОльшее кол-во фоток. Нам нужна галлерея, желательно не позже чем через 2 недели (N дней), у нас распродажа, сможем?"
Ага я такой
https://habr.com/ru/articles/904864/comments/#comment_28227630
Ну, нет... =)
Ситуация как в анекдоте.
Встретились мазахист и садист.
Мазахист: "Ну, бей меня, бей!!!"
Садист: "А...!!! Не буду!!!"
Мне минуса мало.
Опять мимо. Я не против, что бы меня минусовали не только "мальчики', но и "девочки". Но только, что бы они дополнительно оставляли коммент, что бы нельзя было просто так минусовать.
Что бы всем было хорошо.
Какие правила я предлагаю менять? Где это описано в статье, конкретно место?
Я за минусы, если Вы не поняли. И за то, что полезной информации были больше, а не меньше.
Полностью согласен, так это и хорошо. Но это и сложно. Сложно писать такие комменты.
А Хабр вместо поддержки таких авторов, делает наоборот - позволяет ставить минус молча. Моя статья и об этом.
У сообщества не может быть личной неприязни по определению.
Я не против минусов и критики, я против молчаливой критики. Типа такой: ты плохой.
Контейнер решает именно ту задачу, которая описана в предыдущей статье и которая нужна для тестов: создает под дерево зависимостей по требованию с возможностью подмены зависимости на любом уровне. Например глубина дерева зависимостей 5, можно подменить только листовые зависимости.
Никакой контейнер в go не упрощает код. Максимум делает его более структурированным. Потому что все равно придётся регистрировать все зависимости руками. Какой бы контейнер не был. Обьем пакета с зависимостями или конфигурации контейнера всегда примерно одинаков. Autowire невозможен, как в symfony.
По сути это решение НЕ контейнер в классическом его понимании. Он не хранит мета информацию о связях и т.п. Это обычный пакет который создает зависимости. Только фабричные функции там обернуты в провайдеры. Провайдеры позволяют создавать зависимости лениво. Это позволяет в тестах создавать часть дерева зависимостей, и подменять зависимости на любом уровне.
Паралельный запуск условно возможен без изменений API, если добавить правильные локи в метод Use и Mock. Нужно над этим поразмыслить.
Здесь это будут разные инстансы одного и того же сервиса в одном тесте. Нужно решить проблему одновременного чтения и записи моков.
@alexac спасибо за конструктивный диалог
не фабричная функция, а программист, который её пишет. Знать какие зависимости и где используются, понимать, что будет происходить - это хорошо
п 2.b из Вашего коммента. Зачем все это? что бы что?
Единственная реальная проблема такого простого решения - параллельный запуск тестов.
Но это не проблема для очень, очень многих проектов
DI-контейнер не часть принципа, а инверсия зависимостей не предполагает использования контейнера.
Ручное вредрение не противоречит принципу внедрения заимостей.
DI-контейнер - это один из инструментов, который можно не использовать, а можно использовать.
Можно брать кувалду и забивать гвозди..., а можно молоток.
да, это осознанное решение
в реальности будет так как вы напишите, тут нет магии.
Вы должны запаниковать и не запуститься.
Остальное по поводу ошибок - это борьба с проблемой, которой нет, она надуманна.
с этим согласен - нельзя
факт в том - что можно, текущее решение это делает. И многие это делают.
Проблема с тестами решается проще чем изучение uber-fx и затаскивание его в проект.
Об этом здесь "Еще раз про Di-контейнеры в golang" https://habr.com/ru/articles/903300/
к каким вариантам? писать свой DI-контейнер
Второй человек пишет про Юнит-тесты. Но я вот не понимаю, причем тут DI-контейнер? Тесты они ведь Юнит, потому что должны тестировать юнит без контейнера. Когда считается покрытие, то счетчику вообще пофигу используете вы DI или нет. Или у вас не так?
Вы используете DI, что бы удобно писать тесты: в тестах вы "поднимаете" весь DI, частично мокаете и потом запускаете тест. И так для каждого теста. Если в контенере 1000 сервисов, нужно замокать 1, вы его мокаете и запускаете тест. Так получается?
я непонял: для тестов у Вас есть отдельная конфигурация контейнера? в ней только нужная ветка с заглушками? или как?
Если нужен функциональный или интеграционный тест, то скорее всего вы однимите сервис целиком, как "черный ящих" и мокать нужно будет только внешние запросы в БД или другие сервисы. В остальном работают Unit-тесты.
Или я что-то не понимаю? Напишие ситуацию подробнее, интересно понять.
@Vladimir_ch_dev посмотрел befree.ru. Об этом же сайте речь? Там есть полнотекстовый поиск и фасетные фильтры.
можете рассказать на чем ни сделаны, если вы раньше не использовали Эластик? хотя бы в 2-х словах.
Из написанного вижу еще 2 проблемы:
1.
Задача на полнотекстовый поиск есть? Если есть, получается он не работает? Если работает, то из статьи совсем не понятно, как это происходит.
2.
Выглядит так, что значения фильтров не меняются в зависимости от запроса. Т.е. фильтрация может выдать пустое множество. Тогда предстоит реализовать еще и фасетный поиск. Если нужно, то алгоритм есть здесь https://habr.com/ru/articles/517074/
все верно, согласен. А что такое продуктивность? в чем она измеряется? Вот 2 задачи: одна 2 дня, вторая 2 недели? Как понять, какая из них получилась не продуктивно?
Я иногда спрашиваю - а зачем её делать, что бы что? И ответа нет
Проблема в том, что в диалоге нет ничего про value для пользователя и бизнеса. Ну, т.е. мы думаем о целях бизнеса, пользователя или пилим задачи, которые дешевле?
Диалог мог быть начаться так:
И тогда бы этого поста не было.
немного промазал