Ответ 1
Важно понять, что Кинжал был создан после Guice одним из создателей Guice ("Crazy Bob" Lee) после его перехода на Square:
- Весна была выпущена в октябре 2002 года.
- Google первоначально публично выпустил Guice в марте 2007 года.
- JSR-330 формализовал аннотации
javax.inject
в октябре 2009 года, с большим вкладом от Google (Bob Lee), Spring и других игроков отрасли. - Квадрат первоначально был выпущен Dagger 1 публично в мае 2013 года.
- Google первоначально выпустил Dagger 2 публично в апреле 2015 года.
- Квадрат отмечен Кинжалом 1 как устаревший 10 дней назад, 15 сентября 2016 года.
В этом смысле продолжающееся стремление Guice - это не "изобретать колесо" так же, как обслуживание в долговременном и широко потребляемом программном пакете, который полностью предшествует любой версии кинжала. Перечислить и внести изменения в отличия, которые вы указали выше:
- Spring - это платформа с относительно тяжелым весом с множеством интеграций, языком конфигурации XML и привязкой к работе/рефлексии. Приложения, уже использующие Spring, могут использовать Spring injection dependency framework с очень небольшой дополнительной работой.
- Guice - это относительно легкая структура с меньшим количеством интеграции, конфигурацией экземпляра Java и привязкой времени исполнения/рефлексии. С использованием привязок Java вы получаете проверку типа времени компиляции и интеграцию автозаполнения IDE.
- Кинжал - очень легкая структура с очень небольшим количеством интеграций, конфигурацией интерфейса Java/аннотаций и привязками кодов, сгенерированными во время компиляции. Аспект генерации кода делает Dagger очень эффективным в целом и, в частности, в среде с ограниченными ресурсами и мобильных средах. (Android отличается от VM, особенно медленным, поэтому кинжал особенно полезен здесь.)
- Все три из вышеперечисленных структур поддерживают JSR-330, поэтому хорошо обработанная библиотека или приложение могут быть в основном агностическими для используемого контейнера DI.
Помимо этого, следите за шаблонами обслуживания и устаревания и политикой среди любых используемых вами фреймворков, но оставьте это до интеграции и производительности, которые вам нужны, наряду с техническими соображениями вашей команды.