102

私のチームは依存性注入フレームワークを研究しており、Google-GuiceとPicoContainerのどちらを使用するかを決定しようとしています。

フレームワークでいくつかのものを探しています。

  1. 小さなコードフットプリント-小さなコードフットプリントとは、コードベースのいたるところに依存性注入コードを散らかしたくないということです。将来的にリファクタリングする必要がある場合は、可能な限り簡単にする必要があります。
  2. パフォーマンス-オブジェクトを作成および挿入するときに、各フレームワークにはどのくらいのオーバーヘッドがありますか？
  3. 使いやすさ-学習曲線は大きいですか？何かを簡単に機能させるには、コードの山を書く必要がありますか？構成をできるだけ少なくしたい。
  4. コミュニティの規模-コミュニティが大きいということは、通常、プロジェクトが継続して維持されることを意味します。フレームワークを使用したくないので、独自のバグを修正する必要があります;）また、途中で質問があれば、フレームワークの開発者/ユーザーコミュニティが回答できることを願っています。

リストされた基準に対する2つのフレームワークの比較は大いにありがたいです。2つを比較するのに役立つ個人的な経験も非常に役立ちます。

免責事項：私は依存性注入にかなり慣れていないので、この議論に関係のない質問をした場合は、私の初心者を許してください。

4

6 に答える 6

117

検討している依存性注入フレームワークのリストにSpringを含めることをお勧めします。ここにあなたの質問に対するいくつかの答えがあります：

フレームワークへの結合

ピコ-ピコはセッターインジェクションを思いとどまらせる傾向がありますが、それ以外は、クラスはピコについて知る必要はありません。知る必要があるのは配線だけです（すべてのDIフレームワークに当てはまります）。

Guice -Guiceは標準のJSR330アノテーションをサポートするようになったため、コードにGuice固有のアノテーションは必要ありません。Springはこれらの標準アノテーションもサポートしています。Guiceの人たちが使用する議論は、Guiceアノテーションプロセッサが実行されていなければ、別のフレームワークを使用することにした場合、これらは影響を与えないはずだということです。

Spring -Springは、コード内でSpringフレームワークについて言及されないようにすることを目的としています。他にもたくさんのヘルパー/ユーティリティなどがあるので、Springコードに依存したいという誘惑はかなり強いです。

パフォーマンス

ピコ-私はピコの速度特性にあまり精通していません

Guice -Guiceは高速になるように設計されており、リファレンスに記載されている比較にはいくつかの数値があります。確かに、速度が主な考慮事項である場合は、Guiceを使用するか、手作業で配線することを検討する必要があります

春-春は遅くなる可能性があります。それをより速くするための作業があり、JavaConfigライブラリを使用すると処理が高速化されるはずです。

使いやすさ

Pico-設定が簡単です。Picoは、自動配線の決定を行うことができます。非常に大規模なプロジェクトにどのように拡張できるかは明確ではありません。

Guice-設定は簡単です。注釈を追加し、AbstractModuleから継承するだけで、物事をまとめることができます。構成が最小限に抑えられるため、大規模なプロジェクトに適切に拡張できます。

Spring-設定は比較的簡単ですが、ほとんどの例では、設定方法としてSpringXMLを使用しています。Spring XMLファイルは、時間の経過とともに非常に大きく複雑になり、ロードに時間がかかる可能性があります。これを克服するために、スプリングと手動クランクの依存性注入を組み合わせて使用​​することを検討してください。

コミュニティの規模

ピコ-小さい

Guice-中

春-大

経験

Pico-私はPicoの経験があまりありませんが、広く使用されているフレームワークではないため、リソースを見つけるのが難しくなります。

Guice -Guiceは人気のあるフレームワークであり、開発で多くのことを再開している大規模なプロジェクトがある場合は、速度に重点を置くことを歓迎します。構成の分散性について懸念があります。つまり、アプリケーション全体がどのようにまとめられているかを確認するのは簡単ではありません。この点では、AOPに少し似ています。

春-春は通常私のデフォルトの選択です。とは言うものの、XMLは煩雑になり、結果として速度低下が煩わしいものになる可能性があります。手作りの依存性注入とSpringを組み合わせて使用​​することがよくあります。実際にXMLベースの構成が必要な場合、SpringXMLは非常に優れています。Springはまた、他のフレームワークをより依存性注入に適したものにするために多大な努力を払いました。これは、そうするときにベストプラクティスを使用することが多いため、便利です（JMS、ORM、OXM、MVCなど）。

参考文献

于 2010-01-08T14:02:12.963 に答える
26

jamie.mccrindle によって提示された回答は実際にはかなり良いものですが、優れた代替手段 (Pico と Guice の両方) が利用可能であることは明らかなのに、Spring がデフォルトの選択である理由がわかりません。IMO Spring の人気はピークに達しており、現在は (Spring の時流に乗ろうとしている他のすべての「私も」Spring サブプロジェクトと同様に) 生成された誇大宣伝に頼っています。

Spring の唯一の本当の利点はコミュニティのサイズです (率直に言って、サイズと複雑さのために必要です) が、Pico と Guiceのソリューションははるかにクリーンで、より組織的で、よりエレガントであるため、巨大なコミュニティは必要ありません。Pico は Guice よりも柔軟性が高いようです (Pico で注釈を使用することも、使用しないこともできます。非常に効率的です)。 （編集：効率的ではないということではなく、非常に柔軟であると言う意味です。）

Pico の小さなサイズと依存関係の欠如は、控えめに言っても過言ではない大きな利点です。Spring を今すぐ使用するには、何メガをダウンロードする必要がありますか? それは、すべての依存関係を含む、巨大な jar ファイルの厄介な混乱です。直感的に考えると、このような効率的で「小さい」ソリューションは、Spring のようなものよりも優れたスケーリングとパフォーマンスを発揮するはずです。Spring の肥大化によって、本当にスケーラビリティが向上するのでしょうか? ここが異世界か。Spring が「よりスケーラブル」であることが証明 (および説明) されるまで、私は仮定しません。

時々、何か良いもの (Pico/Guice) を作成し、それから無限の新しいバージョンで肥大化や台所のシンク機能を追加する代わりに、手を離しておくことは本当にうまくいきます...

于 2010-07-22T02:28:22.860 に答える
12

注：これは答えというよりもコメント/暴言です

PicoContainer は素晴らしいです。彼らがウェブサイトを修正するだけなら、私はそれに戻るだろう. 今は本当に混乱しています：

現在、私は Guice 2.x を使用していますが、これはサイズが大きく、機能が少なくなっています。ドキュメントを見つけるのがはるかに簡単になり、そのユーザー グループは非常に活発です。しかし、Guice 3 の方向性が何らかの兆候であるとすれば、Spring が初期の頃にそうであったように、Guice が膨張し始めているように見えます。

更新: Pico Container 関係者にコメントを投稿したところ、Web サイトにいくつかの改善が加えられました。はるかに良くなりました！

于 2011-05-12T19:05:28.077 に答える
3

これは古い質問ですが、今日では Android アプリ プロジェクトでDagger ( https://github.com/square/dagger ) を検討できます。Dagger はコンパイル時にコード生成を行います。そのため、起動時間が短くなり、実行時のメモリ使用量が少なくなります。

于 2014-01-29T16:40:22.367 に答える
0

PicoContainer はシンプルで依存関係がないので気に入っていますが。代わりに CDI を使用することをお勧めします。これは Java EE 標準の一部であるため、ベンダー ロックインがありません。

侵入性に関しては、主な問題は、コンテナーの要件と、比較的空の META-INF/beans.xml ファイルの使用 (jar が CDI を使用していることを示す必要がある) と注釈の使用 (標準ですが) です。 )

私自身のプロジェクトで使用する軽量の CDI コンテナーは、Apache Open Web Beans です。このような単純なアプリ (Pico とは異なります) を作成する方法を理解するのに時間がかかりましたが。

public static void main(final String[] args) {
    final ContainerLifecycle lifecycle = WebBeansContext.currentInstance()
            .getService(ContainerLifecycle.class);
    lifecycle.startApplication(null);

    final BeanManager beanManager = lifecycle.getBeanManager();
    // replace Tester with your start up class
    final Bean<?> bean = beanManager.getBeans(Tester.class).iterator()
            .next();

    final Tester b = (Tester) lifecycle.getBeanManager().getReference(bean,
            Tester.class, beanManager.createCreationalContext(bean));
    b.doInit();
}
于 2012-10-22T10:51:59.313 に答える