Google ガイド vs.依存性注入のための PicoContainer

https://stackoverflow.com/questions/2026016

19-09-2019
|

質問

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

私たちのフレームワークではいくつかのことを求めています。

小さいコードフットプリント - 小さいコードフットプリントとは、コードベースのあらゆる場所に依存関係挿入コードのゴミを入れたくないということです。将来的にリファクタリングが必要になった場合、それをできるだけ簡単にしたいと考えています。
パフォーマンス - オブジェクトの作成および挿入時に各フレームワークにかかるオーバーヘッドはどれくらいですか?
使いやすさ - 習得には長い時間がかかりますか?単純なものを動作させるために山ほどのコードを書かなければならないのでしょうか?構成はできるだけ少なくしたいと考えています。
コミュニティの規模 - コミュニティが大規模であるということは、通常、プロジェクトが維持され続けることを意味します。私たちはフレームワークを使用したくないので、独自のバグを修正する必要があります ;) また、途中で発生した質問は、フレームワークの開発者/ユーザーコミュニティによって (できれば) 答えられるでしょう。

リストされた基準に照らして 2 つのフレームワークを比較していただければ幸いです。2 つを比較するのに役立つ個人的な経験も非常に役立ちます。

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

解決

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

フレームワークへの結合

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

ガイス - Guice が標準をサポートするようになりました JSR330 注釈が追加されるため、コード内に Guice 固有の注釈を追加する必要はなくなります。Spring はこれらの標準アノテーションもサポートしています。Guice 担当者が使用する議論は、Guice アノテーションプロセッサが実行されていない場合、別のフレームワークを使用することにした場合でも、これらのプロセッサは影響を及ぼさないはずだというものです。

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

パフォーマンス

ピコ・Picoの速度特性がよく分からない

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

春 - 春は遅いかもしれません。これを高速化するための作業が行われており、JavaConfig ライブラリを使用すると高速化されるはずです。

使いやすさ

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

ガイス - 設定が簡単で、アノテーションを追加し、AbstractModule から継承してバインドするだけです。構成が最小限に抑えられるため、大規模なプロジェクトにも適切に拡張できます。

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

コミュニティの規模

ピコ - 小さい

ガイス - 中くらい

春 - 大きい

経験

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

ガイス - Guice は人気のあるフレームワークであり、開発を何度もやり直す大規模なプロジェクトがある場合には、スピードを重視することは歓迎されます。構成の分散性について懸念があります。つまり、アプリケーション全体がどのように構成されているかを理解するのは簡単ではありません。この点では AOP に少し似ています。

春 - 通常、私のデフォルトの選択は Spring です。とはいえ、XML は扱いにくくなり、その結果生じる速度の低下が煩わしい場合があります。私は最終的に、手作りの依存性注入と Spring を組み合わせて使用することがよくあります。実際に XML ベースの設定が必要な場合は、Spring XML が非常に適しています。Spring はまた、他のフレームワークをより依存性注入に適したものにすることに多大な努力を払っています。これは、そうする際にベストプラクティス (JMS、ORM、OXM、MVC など) を使用することが多いため、便利です。

参考文献

他のヒント

jamie.mccrindle が提示した答えは実際にはかなり良いものですが、より優れた代替手段 (Pico と Guice の両方) が利用可能であることは明らかであるのに、なぜ Spring がデフォルトの選択肢なのか、私は混乱しています。IMO Spring の人気は頂点に達し、現在は (Spring の時流に乗ろうとしている他のすべての「me too」Spring サブプロジェクトとともに)、生成された誇大広告で生きています。

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

Pico の小さなサイズと依存関係の欠如は、過小評価されるべきではない大きな利点です。今 Spring を使用するには何メガをダウンロードする必要がありますか?これは、すべての依存関係を含む巨大な jar ファイルの厄介な混乱です。直観的に考えると、このような効率的で「小規模な」ソリューションは、Spring のようなソリューションよりも拡張性が高く、パフォーマンスも優れているはずです。Spring の肥大化により、本当にスケールが改善されるのでしょうか?ここは奇妙な世界ですか？それが証明される (そして説明される) まで、私は Spring が「よりスケーラブルである」とは想定しません。

場合によっては、良いもの (Pico/Guice) を作成し、無限の新しいバージョンで肥大化した機能やキッチンシンクの機能を追加する代わりに、手を離しておいた方が本当にうまくいくことがあります...

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

ピココンテナは素晴らしいですね。Web サイトを修正してくれれば、私はそれに戻ると思います。今は本当に混乱しています:

http://ピココンテナ.com これは最新のものですが、多くのページに書式設定の問題があり、いくつかのページはまったく機能しません。ページは古いコンテンツから自動変換されたようです。
http://picocontainer.codehaus.org/ バージョン 2.10.2 では時間が止まっているように見えますが、おそらく次のようになります。 すごくいい ページに「おい、古い Web サイトを見ているんだ!」のような内容が表示されていたとしたら、
http://docs.codehaus.org/display/PICO/Home - v 1.x について説明する Confluence Wiki ですが、 ページのどこにもそんなことは書いてないよ！

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

アップデート：Pico Container の人々にコメントを投稿したところ、Web サイトにいくつかの改善が加えられました。今ではかなり良くなりました！

それはあなたがダガー（ https://github.com/square/dagger <考えることができ、古い質問が、今日であります/ A>）あなたのアンドロイドアプリプロジェクトインチダガーは、コンパイル時にコード生成を行います。ですから、実行時間の短い起動時間と少ないメモリ使用量を取得します。

あなたは最小限のDIコンテナ後にしている場合は、

は、フェザーにチェックアウトすることができます。バニラJSR-330のDI機能だけではなく、フットプリントの条件（16K、依存関係のない）と性能がかなり良いです。 Android上で動作します。

私はそれの簡略化のためPicoContainerのように行うと、それが依存関係の欠如だが。それは、Java EE標準の一部であるので、あなたが何のベンダーロックインを持っていないので、私が代わりにCDIを使用することをお勧めします。

侵入性の点で、それは主な問題は、しかし、容器と（ジャーはCDIを使用していることを示すために必要な）比較的空のMETA-INF / beans.xmlファイルの使用及び注釈の使用（の要件であるです彼らは標準装備されています）。

私は自分のプロジェクトのために使用した軽量CDIコンテナは、ApacheオープンWeb Beansのです。それはこのようになります（ピコとは違って）シンプルなアプリを作成する方法を見つけ出すためにしばらく時間がかかったもののます。

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();
}

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow