EJBの数が多すぎますか？

Question

私は現在JavaEE上に大きなソフトウェアベースを開発中です。私たちはJavaEEの一般的なガイドラインに従っています。このガイドラインでは、それぞれの関連する一連の操作がそれぞれ独自のEJBに移行する必要があります。私たちは現在、275種類以上の異なるEJBクラス（ステートレスセッションBean）を持っています。この数字は、その数字の少なくとも2倍になる可能性が最も高いです。

私は、EJBコンテナが多くの異なる種類のEJBを保持するように設計されているかどうかを知りたいと思います。私は、あまりにも多くのクラスを持っていることからパフォーマンスの悪いペナルティを受けることがあるかどうかを知ることに興味があります。アプリケーションサーバレベルの調整によっては、これらの仮説的な問題を緩和することができます。

Glassfish v2とJavaEE 5をsunのJava 6で使用しているため、この特定のプラットフォームに関するアドバイスが最も高く評価されます。

Answer 1

EJBは細分化されている必要があります。そのため、デザインに一貫性がある場合は、何をしているかに問題はありません。

EJBは単なるクラスなので、展開したEJBの数とは正反対の一般的な負荷以外は何も心配はありません。

パフォーマンスが心配な方は、モニタリングやその他のパフォーマンス指標を入力して、新しい機能を追加する際の状況を確認してください。

今日の終わりには、多くのメソッドで少数のクラスを維持するか、より少ないメソッドで多くのクラスを維持しますか？私はどれを選ぶか知っています。深刻なノートで

Answer 2

（私は否決されることなく、「任意のすべてで」言うことができる方法はありますか？）

、必要な数を使用します。私の経験則は、約3語のクラス名で何がしているのかを完全には説明できない場合は、（あまりにも多くのことをやっています。

パフォーマンスが上がるまでは、システムが「あまりにも多くのEJB」に苦しみ始めると、どこかでさらに大きな問題が発生すると思われます。

Answer 3

EJBはクラスではなくコンポーネントであり、その用語で考える必要があり、システム設計を適切に表現する必要があります。

コンポーネントの粒度は、明らかにドメインに依存します。

EJBを使用して（かなり古くなった）コンピュータをモデリングしていると仮定します。抵抗、トランジスタ、コイルなど：これらはポーホスです。チップとボードはコンポーネントです。アセンブリはEARです。

インターフェイスの粒度はコンポーネントの機能を反映する必要があります。

Answer 4

EJBは通常のクラスインスタンスではありません。コンテナ、インスタンスプールなどで余分なメンテナンスが必要です。多くのEJBはサーバーに多くのリソースを必要とします。

私はシステムが何百ものEJBを必要としないと思います。私は90個のEJBを持つアプリケーションにも関わっていましたが、それは悪夢でした：<テスト容易性はなく、展開も大きな課題です。