61

JSR-299 Contexts and Dependency Injection リファレンス実装である Weld は、Spring と Guice の後継者の一種と見なされています。

CDI は、Seam、Guice、Spring など、多数の既存の Java フレームワークの影響を受けました。ただし、CDI には独自の非常に明確な特徴があります。Seam よりもタイプセーフであり、Spring よりもステートフルで XML 中心ではなく、Guice よりも Web およびエンタープライズ アプリケーションに対応しています。しかし、言及されたフレームワークからのインスピレーションと、JSR-299 Expert Group (EG) による多くのコラボレーションと努力がなければ、これらのいずれも実現できませんでした。

http://docs.jboss.org/weld/reference/latest/en-US/html/1.html

Guice と比較して、エンタープライズ アプリケーションで Weld が優れている理由は何ですか? Guiceと比べてメリット・デメリットはありますか？溶接インターセプターと比較して、Guice AOP についてどう思いますか? パフォーマンスはどうですか？

私の選択

最終的に、デフォルトで @Inject 以外にアノテーションがほとんどないクリーンなプログラミング モデルが好きなので、Guice を使用することにしました。CDI よりも Guice で外部ライブラリを使用する方がはるかに簡単です。AOP も、Guice を使用すると非常に単純です。

4

6 に答える 6

53

質問に答える前に、重要な情報を追加させてください。JSR 330 ( @Inject) は Guice および Spring プロジェクト ( 2009 年 5 月の発表) によって標準化され、JSR 299で再利用されています。これは、注入ポイントの宣言に関する基本的な DI メカニズムをカバーしています。

さて、質問に戻りますが、免責事項として、私は Guice よりも Spring の方がはるかに多くの経験があります。

Weld のエンタープライズ機能

  • 代替構成メカニズムは、JSR-299 で非常にクリーンな設計をしており、Java コードの外部で構成メカニズムを使用できます ( beans.xml)。
  • イベントは非常に強力なものであり、JMS にうまく適合します。Guice の Event Bus を見つけたところですが、それがどのように比較されるかはわかりません。
  • ポータブル拡張機能は、既存のテクノロジと統合したり、レガシー コードをクリーンな方法でラップしたりするために使用できる SPI です。

利点/欠点

注: 後でここにいくつかの項目を追加しようとしますが、この回答は予想よりも長くなってしまいました。申し訳ありません。

  • 溶接/CDI

    • 標準化: 何かが標準化され、適切な実装があれば、多くの人がそれを使用します。例: Weldの組み込みスコープは、 GuiceやSpringよりもいくつかのスコープを提供します。これらはすべて拡張できますが、大規模なコミュニティで使用されている場合、アプリケーション フレームワークはむしろ標準スコープに依存します。
    • コンテナのサポート: これは前の項目と似ていますが、採用の主要な議論です。Glassfish や JBoss 6 などの主要なオープン ソース アプリケーション サーバーは、CDI サポートを提供します (こちらを参照)。

  • ギース/春

    • 実際のアプリケーション: 既存のアプリケーションのほとんどは、既に Guice/Spring を使用しています。Spring/Guice は常に標準に基づいて構築されており、標準が存在しない場合や使用できない場合に新しい機能を提供してきました。それぞれのベスト プラクティスに従えば、フレームワークはアプリケーションを標準ベースでクリーンにするのに役立ちます。

AOP とインターセプター

これは非常に議論の多いトピックであり、どちらかを優先することはできません。どちらのメカニズムも非常に強力ですが、少なくともアプリケーションのアーキテクチャを理解している必要があります。Decoratorsと以前に参照したEventsも参照してください。適切なツールを使用するのが最善ですが、開発者がこれらのメカニズムのいずれかを使用する必要がある場合、開発者が概念を理解していることは良いことであることを忘れないでください。

パフォーマンス

残念ながら、私はまだこれを調べることができませんでしたが、特に気付かないうちに多くの機能を提供するフレームワークを使用する場合は、従おうとするいくつかのルールがあります。

  • 可能な限り、実行時に複数のルックアップよりも 1 つの配線ステップを優先してください。
  • 可能であれば、アプリケーションの初期化時にすべての配線を行います。
  • インターセプト ステップまたは AOP プロキシは、いくつかのメソッド呼び出しをスタックに追加します。
于 2010-05-11T13:45:46.030 に答える
20

CDI (溶接) はまだ広く使用されていないため、比較するのは困難です。いくつかのポイント:

  • CDI は、EJB3、JSF、およびその他の JavaEE 標準との統合を念頭に置いて設計されています。CDI には、サードパーティのライブラリを CDI 実装のライフサイクルおよび内部機能と統合できるようにする、いわゆるポータブル拡張機能があります。
  • CDI は考えられるすべてのコーナーケースを念頭に置いて設計されているため、必要なものはすべてカバーされている可能性があります。Spring、Guice、Seam はこのような状態に進化しましたが、CDI はこれら 3 つの経験を利用しています。
  • 私の意見では、CDI インターセプターは、Spring AOP が満たしたすべての要求を満たすことはできません。おそらく同じことが Guice AOP にも当てはまります。AspectJ 構文を使用してインターセプターを定義することはできません。
  • xml 定義がないことは長所と短所の両方であり、一部の人々は (場合によっては当然) xml 構成を好みます。
  • 修飾子アノテーションの拡張使用は (私の意見では) 慎重に使用しないと大きな混乱を引き起こします。
于 2010-04-16T11:04:31.523 に答える
10

Guice ユーザー向けの CDIは良い比較対象です。

于 2013-10-29T13:18:26.133 に答える
8

CDI が Guice に反対している最も重要な機能は、それが Java EE 6 の標準部分であるということです。

この重要性を過小評価することはできません。CDI は、Web アプリケーションのコーディング時に使用する必要がある DI 標準であることを意味します。

しばらく前に、コアモジュールを変更せずに既存の機能をオーバーライドできる追加モジュールを自由に追加できる、適切に準備された標準コアディストリビューションを作成する方法を決定できるテクノロジーを調べました。つまり、追加の jar を追加すると、機能が自動的に有効になります。

デスクトップ アプリケーションと Web アプリケーションの両方で使用されるコード ベースに対してこれを行うための最良の方法は、コードに JSR-330 注釈を使用し、次に CDI または Guice (SVN。 3.0) をエンジンとして使用します。

いくつかのプロジェクトを行った後、Weld で発生する不透明な魔法よりも、Guice 構成が最適であることがわかりました。さらに、Weld で上記のようにやりたいことを行う方法は、追加の jar 内のクラスを @Alternative としてマークし、beans.xml で代替クラスを強制する必要があることを言及する必要があることがわかりました (それはそうではありません)。リファクタリングに強い）。

しかし全体として、JSR-330 を使用すると、以前は非常に面倒で壊れやすかったことを実行できます (newバインドが非常にきつく固定されているため)。これは大きなメリットです。このような必要がある場合は、DI を検討することを強くお勧めします。

于 2010-12-20T19:02:54.467 に答える
5

もう 1 つの差別化要因は、CDI が非常に Java EE 指向であることです。さまざまなJava EE サブシステムを結合するメカニズムを提供します。

すなわち。Bean に で注釈を付けることにより、Bean@Named("book")は統一された EL (式言語) で「book」として認識されるようになります。

次に、たとえば JSF ページで使用できます。

    <h:outputLabel value="Book title:" for="bookTitle"/>
    <h:outputText id="bookTile" value="#{book.title}"/>
于 2010-11-05T12:20:57.913 に答える