1

かなり前に作成された、かなりの数のEJB2ステートレスセッションBeanを含むプロジェクトがあります。これらは、RMIを介してクライアントからアクセスされる最初の行のBeanではなく、特定の機能を実行するためにそのコードによって使用されます。しかし、セッションBeanとして使用しても何も得られないと思うようになりました。

  • RMIを介してアクセスする必要はありません。
  • それらは状態を保持しません。それらは、複雑さを軽減するために最初のBeanセットから除外されたコードにすぎません。
  • それらには、私たちが交換している複数の異なる実装がありません。それぞれが何年もの間そうであったようです（バグ修正と機能追加を除いて）。
  • それらのいずれも、それらを呼び出すBeanから入ってくるトランザクションを変更しません（つまり、新しいトランザクションを必要としない、既存のトランザクションに参加しない、またはその他の方法で変更する必要はありません）。

なぜこれらすべてが、いくつかの静的関数を持ち、EJBトラップがまったくないクラスである必要がないのですか？

4

2 に答える 2

3

私が見ることができる唯一の理由は、クラスタリングの目的のためです（クラスタリングを行っている場合）。つまり、負荷を分散するためにクラスタリングが正しく行われている場合、それらのBeanへのハンドオフは別のマシン上の別のVMにある可能性があります。

そうではない可能性が高く、EJBへの移行は過剰に設計されていました。私もそれに苦しんでいます。

トランザクションだけでは正当化するのに十分ではありませんが、トランザクションを処理する単一のEJBを使用して、コマンドタイプパターンを介して別のコードを呼び出すことができます。

于 2009-07-17T16:17:23.123 に答える
1

ステートレスセッションBeanではなく単純なPOJOであってはならない理由はないようです。これは、 EJB1.xをこのように使用した後に人々が到達した結論だと思います。

これは、 SpringなどのフレームワークがEJBの代替として存在する理由でもあります。

それらを単なる標準のPOJOに変更すると思いますが、ユニットテストと機能テスト（EJBでは少し難しいかもしれません）のセーフティネットがあることを確認してください。

于 2009-07-17T16:17:40.937 に答える