21

シナリオ

  • EJB バージョン 3 を使用して Web アプリケーションを開発しました。
  • システムが展開され、配信され、顧客によって使用されます。

システムをゼロから書き直す必要がある場合、EJB を再び使用しますか?

いいえ: この質問には回答せず、代わりにこちらに回答してください。

はい: あなたの個人的な経験に基づいて、EJB が解決した重要で実際の問題を 1 つ挙げてください。

答えに問題が1 つだけ含まれるようにします。これにより、他の読者が EJB の最高の機能に投票できるようになります。

4

6 に答える 6

5

あなたが話しているEJBのバージョンに依存すると思います。関連する (IMO) バージョンを 2 つだけ説明しましょう。

EJB 2.1 は、レガシー システムの一部の人々によってまだ使用されている可能性があります。それらは、RPC 抽象化として実際に最も多く使用されています。彼らはまた、基本的な ORM (Object-Relational Mapping) システムも提供しました。そして、おっしゃる通り、トランザクションサポートが提供されています。したがって、リモート システムとの通信、オブジェクト指向データの転送、およびトランザクション処理が必要なシステムを構築する場合、EJB は努力する価値があることに気付くかもしれません。それ以外の場合は、近づかないでください。

ただし、EJB 3.0 は大幅に改善されています。以前のバージョンのすべての機能を備えていますが、より簡単な方法で実行されます。また、Spring に似た非常に単純な Inversion-Of-Control フレームワークと、JPA (Java Persistence API) の形式のかなりまともな ORM も提供します。私は EJB 3.0 を使用して実際に楽しんでいます。Spring の場合と同じように EJB 3.0 を使用することを主張することができます。さらに、さらに高度な、またはエンタープライズ仕様の機能がいくつか利用可能です。

于 2008-09-19T21:18:50.897 に答える
2

これは、どの EJB について話しているかによって異なります。MDB は今でも役に立ちます。エンティティ Bean とセッション Bean の場合は、より良いアプローチを確実に見つけることができます。EJB で今でも好きな機能の 1 つはスケーラビリティです。「リモート」オプションを使用すると、必要に応じて EJB を別のサーバーにデプロイできます。しかし、私はこれが本当に必要だとは思いません。それが本当に役に立った巨大なプロジェクトを 1 つしか見たことがありません。

于 2008-09-19T21:02:13.370 に答える
1

過去に EJB 2.1 で多くの作業を行いましたが、それを残してよかったです。

EJB の価値命題は 3.0 にも当てはまり、優れた軽量プログラミング モデルを備えています。トランザクション管理、並行性、データのバージョン管理、状態管理、これらは正しく解決するのが重要な問題であり、Java EE フレームワークは優れた仕事を続けています。

確かに、私は Hibernate と Seam を使用して Java EE 機能の一部をさらに構築しているため、EJB 3.0 自体がメッカであると言うのは厳密には公平ではありません。しかし、Java を完全にあきらめて、Rails のようなより流行に乗ったものに移行するとき、あまりにも多くの開発者が、ことわざで言う赤ちゃんを風呂水と一緒に投げ出しています。

Seam は、プログラマーの労力を非常に少なく抑える優れたグルー フレームワークを提供します。また、プログラミング スタイルを変更することなく、EJB と POJO のどちらが適しているかをプロジェクトごとに決定できます。

于 2008-09-19T21:42:26.313 に答える
1

Java ee プラットフォームを使用する主な理由は、当然のことです。並行性、可用性、トランザクション管理、メッセージング、および管理の問題を完全に精査され、準拠し、互換性のあるプラットフォームで解決するプラットフォームが必要です。はい、ライブラリのホスト全体を接着してTomcatの上に平手打ちすることで、すべて自分で行うことができますが、標準を実施し、完全に精査されたプラットフォームに書き込むことができるのに、互換性と機能セットを精査して管理するのに時間を無駄にする必要はありません. どの ee コンテナも tck を渡さなければなりません。さもなければ、Java EE モニカを運ぶことはできません。

ejb の「軽量」や「タイプ」などについて、さまざまな人が挙げていることは不要です。プラットフォームの機能セットや、利用するライブラリの完全な内部互換性を保証する必要がない場合、ejb (別名 Java ee プラットフォーム) は過剰です。しかし、企業の品質問題 (最初の段落を参照) を本当に解決しているのであれば、ejb と Java ee プラットフォームが必要なものを提供してくれます。

于 2014-09-02T02:05:15.937 に答える
0

EJB、または一般にJ2EEを使用するときに多くの問題を抱えているのは、EJBを実行しているアプリケーションサーバーへの依存関係です。appserverは、特定のオペレーティングシステムリリースとJVMバージョンのセットでサポートされる傾向があります。ランタイム環境の重要な部分にソースコードがないことも、課題になる可能性があります。

原則として、あるベンダーから別のベンダーに移行することは可能ですが、仕様の実装方法のわずかな違いを十分に認識し、ベンダー固有の拡張機能に近づかないようにする必要があります。

そうは言っても、私がさらされたアプリサーバーは、その中で実行されているコードからの非常に多くの悪用を処理し、非常にうまく機能することができます。

于 2008-09-20T18:46:51.783 に答える
0

設定より規約。

EJB 3のデフォルトの動作は、多くの場合、望ましい動作です。EJB 2.1の主な問題は、冗長な構成ファイルの必要性であったと思います。新しい注釈ベースの構成は、この問題のほとんどを解決します。

于 2009-05-26T08:14:07.277 に答える