SpringやDaggerがあるのに、なぜGuiceを使うのか、開発するのか？[終了しました]。

質問

私の知る限り、Daggerはコードを生成しますが、GuiceとSpringは実行時処理に依存するため、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の精神的な後継者であると考えることもできますが、Daggerが提供するのは 最適化されたサブセット のみを提供するものです。

上にあるような差異を列挙して修正すること。

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

さらに、使用するフレームワークのメンテナンス/非推奨のパターンやポリシーに目を向けてください。チームの知識と経験、リフレクションや実行時設定の必要性、統合や実行時パフォーマンスの必要性に基づいて、おそらく上記のいずれかが際立って見えることでしょう。とはいえ、他のフレームワークも存在するので、新しい選択肢や上記のフォークにも目を向けてください。