6

私はEJB3（アプリとWebサービスレイヤーの場合はHibernate + Glassfish、WebUIの場合はLifton Glassfish）を使用してJavaで多層金融処理アプリケーションを開発中です。私のビジネスロジックを置きます。

このプロジェクトが開始されたとき、私たちの最初の概念は、ビジネスロジックの大部分をステートレスセッションBeanに入れることでした。ただし、時間が経つにつれて、EJBフレームワークによって提供される依存性注入が制限されすぎることがわかりました。そのため、ビジネスロジックの多くは、ステートレスセッションBeanの@PostConstructメソッドでGuiceによってアセンブルされるPOJOになりました。 。この進歩により、セッションBeanとPOJOの間のビジネスロジックが断片化されました。私は、これを修正するためのアプローチを見つけようとしています。

最初に、Web層でセッションBeanのリモートインターフェイスを使用して、UIとWebサービスレイヤーの両方からアクセスできるいくつかの機能を実行しようとしました。これは、@WebService注釈付きのステートレスセッションBeanによって提供されます。これは、永続性とパフォーマンスの観点からは悪夢であることが判明しました。エンティティグラフが非常に大きくなる可能性があり、分離されたエンティティグラフを永続性コンテキストに再アタッチするとエラーが発生しやすいことが判明したため、ソリューションはオブジェクトの受け渡しを開始することでした。必要な場所でデータベースからエンティティを検索します。

私の基本的な質問はこれです：ビジネスロジックをセッションBeanとPOJOのどちらにするかを決定するために、どのような原則とガイドラインを提案できますか？複雑なオブジェクトグラフがある場合、エンティティBeanを渡すことが理にかなっているのはいつですか。

4

2 に答える 2

1

JPA、EJB3、および Wicket を使用して Web アプリケーションを構築しているときに、これに苦労しました。クエリを繰り返してデータベースに負荷をかける方が、メモリ内に多数の大きなエンティティを保持するよりもスケーラブルであるため、エンティティ自体ではなく ID のみを渡すことにしました。

この決定には、Wicket とそのモデルの概念が大きく関係していました。それらの loadableDetachableModel は、ID を保持しながら、使用されていないエンティティをクリーンアップします。エンティティが再び必要になったときにエンティティを取得する方法を知っている load() メソッドが実装されています。私の場合は、ステートレス セッション Bean を呼び出します。また、persist() メソッドがステートレス Bean を呼び出して変更を永続化します。このモデル クラスは、私が実際に渡しているものです。Wicket は表示と入力の検証に関連するロジックのみを処理し、モデル クラスに ejb を挿入するだけで済みます。おそらく、アプリで同様のものを作成できます (リフトが提供するものはわかりません...)。

これはうまくいきましたが、私は特に複雑なビジネス ロジックを持っていないので、永続化する必要のある変更をロジックの小さな単位と単一のページに分離することができます。

于 2008-11-07T23:22:41.750 に答える
0

多くの「システム」サービス（インジェクションなど）が必要な場合は常に、ステートレスBeanを使用します。それ以外の場合-POJO。POJOははるかに柔軟性があります。

ただし、単純な（アクセサー？）メソッド（WebサービスやBeanなど）では、いくつかの単純な作業を実行して結果を返すことができます。

于 2008-10-30T20:01:05.563 に答える