Зачем использовать/разрабатывать Guice, когда у вас есть весна и кинжал?

Насколько мне известно, Dagger генерирует код, в то время как Guice и Spring полагаются на обработку во время выполнения, поэтому Dagger работает быстрее, но требует больше работы со стороны программиста. Из-за предела производительности это хорошо для разработки мобильных (Android).

Однако, когда мы остаемся с Guice и Spring, последний имеет множество интеграций. Какой смысл разрабатывать/использовать Guice, если мы можем использовать Spring Framework (что делает в основном то же самое, но предлагает более простой доступ к базе данных)?

Разве Google не пытается изобрести колесо, создав собственный инструмент DI, вместо того, чтобы использовать (и, возможно, способствовать) Spring Framework?

Я ищу дерево решений, которое ведет через выбор инструмента DI.

Ответ 1

Важно понять, что Кинжал был создан после Guice одним из создателей Guice ("Crazy Bob" Lee) после его перехода на Square:

В этом смысле продолжающееся стремление Guice - это не "изобретать колесо" так же, как обслуживание в долговременном и широко потребляемом программном пакете, который полностью предшествует любой версии кинжала. Перечислить и внести изменения в отличия, которые вы указали выше:

  • Spring - это платформа с относительно тяжелым весом с множеством интеграций, языком конфигурации XML и привязкой к работе/рефлексии. Приложения, уже использующие Spring, могут использовать Spring injection dependency framework с очень небольшой дополнительной работой.
  • Guice - это относительно легкая структура с меньшим количеством интеграции, конфигурацией экземпляра Java и привязкой времени исполнения/рефлексии. С использованием привязок Java вы получаете проверку типа времени компиляции и интеграцию автозаполнения IDE.
  • Кинжал - очень легкая структура с очень небольшим количеством интеграций, конфигурацией интерфейса Java/аннотаций и привязками кодов, сгенерированными во время компиляции. Аспект генерации кода делает Dagger очень эффективным в целом и, в частности, в среде с ограниченными ресурсами и мобильных средах. (Android отличается от VM, особенно медленным, поэтому кинжал особенно полезен здесь.)
  • Все три из вышеперечисленных структур поддерживают JSR-330, поэтому хорошо обработанная библиотека или приложение могут быть в основном агностическими для используемого контейнера DI.

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