web-dev-qa-db-ja.com

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

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

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

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

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

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

javadependency-injectionguicepicocontainer
97
austen

検討している依存性注入フレームワークのリストにSpringを含めることもできます。質問への回答を次に示します。

フレームワークへの結合

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

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

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

性能

Pico-Picoの速度特性にあまり詳しくない

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

春-春は遅くなる可能性があります。より高速にする作業があり、JavaConfigライブラリを使用すると速度が向上します。

使いやすさ

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

Guice-簡単に設定できます。注釈を追加し、AbstractModuleから継承してすべてをバインドします。構成が最小限に抑えられているため、大規模プロジェクトに適しています。

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

コミュニティサイズ

ピコ-小

Guice-Medium

春-大

経験

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

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

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

参照資料

112
Jamie McCrindle

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

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

Picoの小さなサイズと依存関係の欠如は、控えめにすべきではない大きな勝利です。今すぐSpringを使用するには、何メガグラムをダウンロードする必要がありますか？それはすべての依存関係を持つ巨大なjarファイルの大量の混乱です。直感的に考えると、このような効率的で「小さな」ソリューションは、Springのようなものよりも優れた拡張性とパフォーマンスを発揮するはずです。 Springの肥大化は本当に拡張性を高めるのでしょうか？この奇妙な世界ですか？ Springが実証される（そして説明される）までは、Springが「よりスケーラブル」であると仮定しません。

ときどき良いもの（Pico/Guice）を作成してから、無限の新しいバージョンで肥大化とキッチンシンク機能を追加する代わりに、それを手に入れないことが本当にうまくいく...

25
Manius

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

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

  • http://picocontainer.com これは最新ですが、多くのページにフォーマットの問題があり、いくつかのページがまったく機能しません。ページは古いコンテンツから自動変換されたようです。
  • http://picocontainer.codehaus.org/ バージョン2.10.2では時間的にフリーズしているようです-really Niceページに「ねえ、あなたは古いWebサイトを見ている！」
  • http://docs.codehaus.org/display/PICO/Home -v 1.xをドキュメント化したconfluence wikiですが、ページのどこにも書かれていません！

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

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

11
Joshua Davis

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

2
A.C.Andreani

ミニマルなDIコンテナーを使用している場合は、 Feather を確認できます。 Vanilla JSR-330 DI機能のみですが、フットプリント（16K、依存関係なし）およびパフォーマンスの点では非常に優れています。 Androidで動作します。

1
Cellux

PicoContainerはシンプルであり、依存関係がないため、気に入っています。代わりにCDIを使用することをお勧めします。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();
}
0
Archimedes Trajano