Comments 5
В чем глобальные преимущества перед стандартным DI-контейнером? Просмотрел довольно бегло эту и предыдущую статьи и не понял, если честно :)
Вот список ключевых преимуществ. Если в 2-х словах, то это не библиотека, а помощник, который пишет налету код для построения объектов, у которых есть свои зависимости, у которых есть свои зависимости … и т.д., т.е. код композиции объектов. Если что-то идет не так-то будут ошибки компиляции, а не исключения во время выполнения. Сгенерированный код не бросает исключений, не использует отражение типов, работает очень быстро и не тратит больше памяти, так как это обычный код, который вы бы написали руками.
Представьте, что у вас нет библиотек DI. Вы пишете свой код в парадигме DI (все зависимости внедряете, а не создаете внутри, программируете на основе абстракций и т.п.). Ту часть вашего кода, которая собирает все объекты воедино Pure.DI напишет за вас.
Давно смотрю за развитием библиотеки, очень интересно даже с точки зрения реализации. Но давно хотел спросить, какие предпосылки были для создания такого решения? Да, я вижу описания фичей, что всё статически, ошибки на этапе компиляции и т.д. Но в реальности, даёт ли это что-то в сумме?
Я хочу сказать, что я давно использую DI, ещё со времён Autofac, потом перешли дружно на решение майков. В различных проектах и кейсах, в монолитах и микросервисах, под нагрузками, под требованиями с низким latency, т.д., но как-то не припомню, чтобы DI был проблемой и вносил заметные задержки. Понятно, что я не получаю зависимости в hot path, в циклах. Но там, где он используется его влияние крайне мизерное, чтобы это стало заметным. Иногда требуется агрессивная оптимизация, тогда приходится чем-то жертвовать, но под нож DI почти никогда не попадет, и таких случаев совсем мало на фоне основных задач бизнес-логики.
Да, из неприятного, это ошибки рантайм. Но они также довольно редкие и фиксятся быстро.
Вот на практике, есть ли живой профит, который прям зарешал?
Спасибо за интерес!
Вы совершенно правы. В плане производительности классические библиотеки DI хорошо справляются со своими задачами. И действительно, при разрешении зависимостей бывает нужно идти на компромиссы только в горячих местах. Pure.DI помогогает избежать большинства даже этих компромиссов. Я использовал Pure.DI при написании библиотек, где приходилось выжимать всю производительность до капли и там этот генератор показывал себя замечательно и не надо было думать где использовать DI, а где кто-то выкручиваться иначе. Ещё в плане производительности Pure.DI сильно выигрывает при первом разрешении объектов, так как время на подготовку ему не нужно.
А вот что касается ошибок времени выполнения, по своему опыту я часто наталкиваюсь на них в повседневной работе с классическим DI, скорее всего я менее внимательный чем вы. И для меня проверки на этапе компиляции особо полезны. Эти ошибки исправляются быстро, это да, но у меня эти ошибки пролазили в сборки приложений/сервисов, особенно когда упор делался на модульные тесты, а интеграционных было мало.
В сумме мне кажется, Pure.DI мог бы быть очень полезен для написания библиотек/фреймворков. Он и на производительность совсем не повлияет и зависимостей ни каких не добавляет и работатет в любых условиях/платформах/девайсах. Также в геймдеве мог бы помочь.
Новое в Pure.DI к концу 2024 года