依存性注入のためのGoogle Guice対PicoContainer

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

私たちは私たちのフレームワークでいくつかのものを探しています：

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

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

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

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

フレームワークへの結合

ピコ -ピコはセッター注入を妨げる傾向がありますが、それ以外の場合、クラスはピコについて知る必要はありません。知る必要があるのは配線だけです（すべてのDIフレームワークに当てはまります）。

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

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

パフォーマンス

ピコ - ピコの速度特性に慣れていない

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

春 -春は遅くなることがあります。これをより速くするための作業があり、JavaConfigライブラリーを使用することで速度が向上します。

使いやすさ

Pico-設定が簡単です。Picoはいくつかのautowire決定を行うことができます。非常に大規模なプロジェクトにどのように拡張できるかは不明です。

Guice-設定が簡単で、注釈を追加し、AbstractModuleを継承して、物事をバインドします。構成が最小限に保たれるため、大規模なプロジェクトに適切にスケーリングします。

Spring-構成は比較的簡単ですが、ほとんどの例では構成の方法としてSpring XMLを使用しています。Spring XMLファイルは、時間の経過とともに非常に大きく複雑になり、ロードに時間がかかる場合があります。これを克服するには、Springと手動クランクのDependency Injectionを組み合わせて使用​​することを検討してください。

コミュニティのサイズ

ピコ -小

ギス -ミディアム

春 -大

経験

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

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

春 -通常、春は私のデフォルトの選択です。とはいえ、XMLは扱いにくくなり、結果としてスローダウンが煩わしくなります。私はしばしば手作りの依存性注入と春の組み合わせを使用することになります。実際にXMLベースの構成が必要な場合、Spring XMLは非常に優れています。Springはまた、他のフレームワークをより良い依存性注入対応にするために多くの努力を費やしました。これは、そうするときにベストプラクティスを使用することが多いので便利です（JMS、ORM、OXM、MVCなど）。

参考文献

• ピコ
• ギス
• 春
• 春/ギス/ピコ比較
• 別のSpring / Guiceパフォーマンス比較

jamie.mccrindleが提示した答えは実際にはかなり良いですが、優れた代替手段（PicoとGuiceの両方）が利用可能であることがかなり明らかであるのに、Springがデフォルトの選択である理由が混乱しています。IMOスプリングの人気はピークに達し、現在、生成された誇大広告から消えています（スプリングバンドワゴンに乗ろうとしている他のすべての "私も"スプリングサブプロジェクトと共に）。

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

ピコの小さなサイズと依存関係の欠如は、控えめに言ってはならない大きな勝利です。Springを使用するためにダウンロードする必要のあるメグはいくつありますか？それは依存関係のあるすべての巨大なjarファイルのぎくしゃくした混乱です。直感的に考えると、このような効率的で「小さな」ソリューションは、Springのようなソリューションよりもスケーリングとパフォーマンスが優れているはずです。スプリングの膨らみは本当にそれをより良くするでしょうか？この奇妙な世界ですか？それが証明される（そして説明される）まで、Springが「よりスケーラブル」であるとは想定しません。

時々良いもの（Pico / Guice）を作成し、無限の新しいバージョンで膨らみやキッチンのシンク機能を追加するのではなく、それから手を離します...本当にうまくいきます...

注：これは回答ではなくコメント/暴言です

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

• 最新のhttp://picocontainer.comですが、多くのページにフォーマットの問題があり、一部のページがまったく機能しません。ページが古いコンテンツから自動変換されたようです。
• http://picocontainer.codehaus.org/バージョン2.10.2で間に合うように見える- ページが「ねえ、あなたは古いウェブサイトを見ている！」のようなことを言っていたら本当にいいでしょう。
• http://docs.codehaus.org/display/PICO/Home-v 1.xをドキュメント化しているコンフルエンスウィキですが、ページのどこにもそうは書かれていません！

私は今、Guice 2.xを使用していますが、それより大きく、機能も少ないです。ドキュメントを見つけるのははるかに簡単で、そのユーザーグループは非常にアクティブです。しかし、Guice 3の方向性が何らかの兆候である場合、Guiceが膨れ始めているように見えます。これは、Springが初期の頃に戻ったようにです。

更新：Pico Containerの人々にコメントを投稿しました。彼らはWebサイトにいくつかの改善を加えました。はるかに良くなりました！

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

ミニマルなDIコンテナーが必要な場合は、Featherをチェックしてください。Vanilla JSR-330 DI機能のみですが、フットプリント（16K、依存関係なし）とパフォーマンスの点で非常に優れています。アンドロイドで動作します。

私はPicoContainerが好きですが、そのシンプルさと依存関係の欠如です。CDIはJava EE標準の一部なので、ベンダーロックインがないため、代わりにCDIを使用することをお勧めします。

侵入性に関しては、主な問題は、コンテナーの要件と、比較的空の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();
}