[解決済み] SpringとDaggerがあるのに、なぜGuiceを使う/開発するのですか？[クローズド]です。

質問

私の知る限り、Daggerはコードを生成しますが、GuiceとSpringは実行時処理に依存します。したがって、Daggerは速く動作しますが、プログラマー側の作業がより多く必要です。そのため、Daggerは高速に動作しますが、プログラマー側の作業が増えます。パフォーマンス面で優れているため、モバイル（Android）開発に向いています。

しかし、GuiceとSpringになったとき、後者にはたくさんの統合があります。Spring Framework（基本的に同じことをするが、より簡単なデータベースアクセスなどを提供する）を使えるなら、Guiceを開発/使用する意味はあるのでしょうか？

Googleは、Spring Frameworkを使う（そしておそらく貢献する）代わりに、独自のDIツールを作ることで車輪の再発明をしようとしているのではないでしょうか？

DIツールを選択する際のガイドとなるようなデシジョンツリーを探しています。

どのように解決するのですか？

DaggerはGuiceの後に、Guiceのクリエイターの一人が作ったものであることを認識しておく必要があります( クレイジー・ボブ" リー スクウェアに移籍していた）。

• Springは、もともと 2002年10月 .
• GoogleがGuiceを一般に公開したのは 2007年3月 .
• JSR-330 形式的 javax.inject のアノテーションは 2009年10月 Google (Bob Lee)、Spring、その他業界関係者の多大なるご協力を得ています。
• スクウェアがDagger 1を一般に公開したのは 2013年5月 .
• GoogleがDagger 2を一般に公開したのは、もともと 2015年4月 .
• Squareは、この質問がなされる10日前に、Dagger 1を非推奨とマークしています。 2016年9月15日（金 .

その意味で、Guiceの継続的な管理は車輪の再発明ではなく、Daggerのどのバージョンよりもずっと前からある、長期間にわたって広く消費されているソフトウェアパッケージのメンテナンスなのです。DaggerはGuiceの精神的後継者であると考えることもできますが、Guiceが提供しているのは 最適化されたサブセット Guiceの機能の

上記にある相違点を列挙し、修正すること。

• Springは、多くの統合、XML設定言語、ランタイム/リフレクティブバインディングを持つ比較的ヘビーウェイトなフレームワークです。すでにSpringを使用しているアプリケーションは、Springの依存性注入フレームワークをほとんど追加作業なしで使用できる。
• Guiceは比較的軽量なフレームワークで、統合、Javaインスタンス設定、ランタイム/リフレクティブバインディングの数が少ないのが特徴です。Javaバインディングを使用することで、コンパイル時の型チェックとIDEオートコンプリートの統合を得ることができます。
• Daggerは非常に軽量なフレームワークで、統合機能はほとんどなく、Javaインターフェース/アノテーションの設定、コンパイル時に生成されるコードバインディングを備えています。コード生成の側面から、Daggerは全体的に、特にリソースが限られたモバイル環境において非常に高いパフォーマンスを発揮します。(AndroidのVMはリフレクションが特に遅くなる点でサーバーJREと異なるため、Daggerはここで特に役に立ちます)。
• 上記の3つのフレームワークはすべてJSR-330をサポートしているので、うまく作られたライブラリやアプリケーションは、使用するDIコンテナにほとんど左右されないことができます。

さらに、使用するフレームワークの保守・廃止のパターンやポリシーに目を向けてください。あなたのチームの知識と経験、リフレクションや実行時設定の必要性、統合や実行時パフォーマンスの必要性に基づいて、おそらく上記のうちの1つが際立って見えることでしょう。とはいえ、他のフレームワークも存在するので、新しい選択肢や上記のフォークにも目を向けてください。