私は現在、JavaEE に基づいた大規模なソフトウェアを開発しています。関連する操作の各セットを独自の EJB に入れる必要があるという JavaEE の一般的なガイドラインに従いました。現在、275 を超えるさまざまな EJB クラス (ステートレス セッション Bean) があります。この数は、少なくともその数の 2 倍になる可能性が最も高いでしょう。
EJB コンテナーが多くの異なる種類の EJB を保持するように設計されているかどうかを知りたいです。このようなクラスが多すぎるとパフォーマンスが低下するかどうか、また、アプリケーション サーバー レベルの微調整によってこれらの仮想的な問題を軽減できるかどうかを知りたいと思っています。
Sun の Java 6 で JavaEE 5 とともに Glassfish v2 を使用しているため、この特定のプラットフォームに関するアドバイスをいただければ幸いです。
EJB はきめの細かいものである必要があるため、設計に一貫性があれば問題はありません。
EJB は単なるクラスであるため、デプロイした EJB の数に直交する一般的な負荷を除いて、心配する必要はありません。
パフォーマンスが心配な場合は、監視またはその他のパフォーマンス メトリックを設定し、新しい機能を追加するときに状況がどうなるかを確認してください。
結局のところ、多くのメソッドを持つ少数のクラスを維持するのと、少数のメソッドを持つ多数のクラスを維持するのとではどちらがよいでしょうか? どちらを選ぶかはわかっています。
EJB はクラスではなくコンポーネントであり、その用語で考えて、システム設計を適切に表現する必要があります。
コンポーネントの粒度は明らかにドメインに依存します。
EJB を使用して (かなり昔ながらの) コンピュータをモデル化しているとします。抵抗器、トランジスタ、コイルなど: これらはポジョです。チップとボードはコンポーネントです。アセンブリは EAR です。
インターフェイスの粒度は、コンポーネントの機能を反映する必要があります。
EJB は単なる通常のクラス インスタンスではありません。コンテナー、インスタンス プールなどで追加のメンテナンスが必要です。多くの EJB は、サーバーで多くのリソースを必要とします。
システムに何百もの EJB が必要だとは思いません。私も 90 個の EJB を使用するアプリケーションに関与していましたが、それは悪夢でした。