0

私は最近、Web アプリケーションの作成を含むプロジェクトを任されました。私はJava EEをやったことがありません。Web 上の多くのリソースは古く、さまざまな標準と Java テクノロジの現在の違いを理解するのに苦労しています。

当初、依存性注入、JPA、セッション管理、および Web サービスのために、EJB 3.1 が本当に必要だと思っていました。私は Glassfish で実験を始めましたが、Tomcat で書く必要があると言われました。だから私は何が必要なのか、Tomcatに何をどのように入れればそこにたどり着くのかを理解しようとしてきました。EJB が必要なのかどうかさえ疑問に思うようになりました。

私は、MVC アーキテクチャに JFS を使用したいと考えています。それについて学ぶ中で、ManagedBeans と CDI の両方に出くわしました。これは、前者を時代遅れにするものもあれば、単体テストを有効にしたいすべての依存性注入機能を提供しているように見えるものもあります。また、Hibernate などの形で EJB の外部に JPA を取得できることにも気付きました。さらに、とにかく必要かどうかわからないWebサービスは、今は名前が思いつかない別の標準の形で提供されているようで、これも個別にインストールできます。

ここでの私の主な問題は、セッション管理と状態です。EJB がやるべきことは、@Stateless/@Stateful と @Local/@Remote を提供することだけのように思えます。ただし、私が理解しているように、これの一部は既にサーブレット コンテナー内のセッション管理の形で存在しています...しかし、決定するために説明する必要がある主な違いがどれだけあるか、またはどのような違いがあるかはわかりません。これらのものが必要な場合。

そこで私の質問は、EJB を検討する価値があるかどうか、または他のライブラリやテクノロジの形で十分かどうかを判断するために知っておく必要がある、基本的で本質的な違いは何ですか? 私はグーグルとユーズネットのいたるところにいましたが、この情報をどこにも見つけることができませんでした。

もうちょっと考えただけ。私が理解しているように、 @Stateful Bean アノテーションはスレッドセーフな状態保存を提供します。私はおそらくスレッドを直接使用するつもりはありませんが、Java が舞台裏で多くのことを行っていることは知っており、特に EE を疑っています。状態を保持する必要がある場合、これが既に提供している場合、スレッドを処理したくありません。

4

3 に答える 3

3

ManagedBean

Java EE 6 にbeansはmanaged、いずれかの方法で定義する 3 つの異なる方法があります。

@javax.faces.bean.ManagedBean

JSF 2.0 では、faces-config.xml でマネージド Bean を宣言するこのアノテーションが導入されました。この注釈は、式言語から Bean にアクセスするために使用されます。

@javax.inject.Named

EE 6 コンテナー CDI では、この注釈は、Bean に名前を提供する組み込みの修飾子型であり、EL からアクセスできるようにします。

@javax.annotation.ManagedBean

このアノテーションは、Java EE の他の場所で使用するために JSF マネージド Bean を一般化しようとします。

EE 6 コンテナーにデプロイする場合 (Tomcat または別のサーブレット コンテナーを使用する場合は、Web アプリに Weld jar を追加することで CDI を取得することもできます)、実際に を使用する理由はありません@javax.faces.bean.ManagedBean。@javax.inject.NamedCDI サービスを利用するだけです。

CDI

CDI 仕様の目的の 1 つは、Web 層とトランザクション サービスを統合して、開発者が Java EE プラットフォームの Web アプリケーションで JSF と一緒に EJB を簡単に使用できるようにすることです。CDI を使用すると、とりわけ次のサービスを利用できます: 明確に定義されたライフサイクルcontexts(seam 2 と対話スコープの影響を受ける)、インターセプター、デコレーター、イベントDependency injectionなどの疎結合機能、およびサードパーティ フレームワークを Java EE に統合できる移植可能な拡張機能SEAM 3 拡張のような 6 つの環境

マネージド Bean と EJB サービス

まず、CDI はマネージド Bean に適用されます。一部のマネージド Bean は EJB です。マネージド Bean で EJB サービスを使用する必要がある場合は、@Stateless,@Statefulまたは@Singletonアノテーションを追加するだけです。IMO それらは補完的なテクノロジーとして機能し、注釈を追加するだけで柔軟かつ段階的な開発を行うことができます。

では、プレーンなマネージド Bean の代わりにセッション Bean を使用する必要があるのはどのような場合でしょうか。

CDI に欠けている EJB 機能が必要な場合: 宣言型トランザクション、同時実行管理、プーリング、リモートまたは Web サービスの呼び出し、タイマー、および非同期メソッドの呼び出し。

もちろん、サードパーティのライブラリを使用してすべての側面を取得することもできますが、これによりプロジェクトがさらに複雑になります。機能面では、IMHO EJB が実装する場所です。

  • ビジネス ロジック。ビジネス ロジックと Web 層ロジックをきれいに分離できます (EJB ではなく CDI 管理 Bean である「JSF バッキング Bean」によって実装されます)。
  • アプリケーションへのエントリポイント (RMI または HTTP 経由で配信されるリモート呼び出しのエンドポイント) であるコンポーネントにとって最も意味のある機能

最後に、EJB サービスが必要な場合は、アプリケーション サーバー (GlassFish や Jboss AS など) が必要です。CDI サービスのみが必要な場合は、サーブレット コンテナー (Tomcat など) と CDI ライブラリが必要です。

于 2011-09-24T15:18:25.590 に答える
1

EJBによって提供される機能、つまりセキュリティとトランザクション管理が必要ですか？答えが「はい」の場合、EJBが適切なオプションである可能性があります。答えが「いいえ」で、依存性注入のみが必要な場合は、CDIが適切なオプションになる可能性があります。Spring（依存性注入、Springセキュリティなど）などの他のサードパーティ製品でも同様の機能を利用できますが、どちらを使用するか（EJBなど）を決定することは、多くの場合、以前の問題です。スキルセット。

私の意見では、以前の制約がない場合、Java仕様に準拠することは良い投資です。

于 2011-09-22T23:13:51.507 に答える
1

CDI から始めて、要件が必要な場合は EJB に進むことをお勧めします (これは実際には POJO の上に 1 つの注釈を追加します) (言われたとおり - トランザクション性、Web サービス、JMX、タイマー、EJB 非同期)呼び出し）。

エントリ ポイントがトランザクション内の呼び出しを包含し、複数のエントリ ポイントを定義できる EJB であるアプリケーションを開発することは非常に合理的です。次に、EJB はビジネス ロジックを含む CDI Bean を呼び出します。

また、TomEEは、Apache Tomcat の上に開発された認定済みの Java EE 6 Web プロファイルであることも注目に値します。

于 2011-10-08T13:31:27.427 に答える