0

ここで言う「EJB」とは、EJB 3.x のことです。

EJB は初めてで、すべてのビジネス ロジックを異なる Bean に最適にマップする方法を考えています。極端な場合、KISS を使用して、アプリケーションのビジネス ロジックを 100% 処理する膨大な数のメソッドを持つモノリシック EJB を 1 つだけ持つことができます。反対に、ビジネス ロジックを関数レベル ( List<User> getUsersFromMars()) まで分割し、それぞれ 1 つのパッケージ、1 つのクラス、および 1 つのメソッドで構成される無数の EJB を持つことができます。

Extreme #1:
    my-ejb.jar/
        com.me.myorg.MonolithicBean
            List<User> getUsersFromMars();
            List<User> getUsersFromVenus();
            //... a bazillion methods

Extreme #2:
    my-mars-ejb.jar/
        com.me.myorg.MarsBean
            List<User> getUsersFromMars();
    my-venus-ejb.jar/
        com.me.myorg.VenusBean
            List<User> getUsersFromVenus();
    //... a bazillion EJBs with 1-and-only-1 method each

明らかに、ベスト プラクティスは、これら 2 つの両極端の間のある種の仲介戦略を指示するものだと思います。アプリのビジネス ロジックを Bean に分解し、それらを正しいレベル (EJB、パッケージ、クラス、またはメソッド) でモジュール化して再利用可能、スケーラブル、安全にする方法について、Java/Oracle は何と言っているのでしょうか?

4

1 に答える 1

2

この質問は EJB に固有のものではなく、OO 設計、さらには一般的な設計に関するものだと思います。

頻繁に繰り返されるパターンは、ビジネス ロジックを DAO とサービスに分割できるというものです。DAO は、Customer などの単一の (ドメイン) エンティティに関連するすべての操作を処理します。データ ソース (通常はデータベース) とのみやり取りし、save、update、delete などのメソッドだけでなく、getBySomething メソッドも備えています。このような DAO は、特定のビジネス ケースに応じて、通常 1 ～ 15 のメソッドを持つことができます。

次に、経験則として、複数のエンティティと対話したり、他のシステム (JMS キュー、メール システム、Web サービスなど) と対話したり、検証を実行したり、セキュリティを提供したりするサービスがあります。これらはビジネス ロジックの動詞を形成し、通常、購入などの特定のビジネス コンセプトを中心にしています。したがって、purchaseGood、purchaseOffer、calculateReduction などのメソッドを使用して、架空の PurchaseService を作成できます。繰り返しますが、これには 1 から 15 または 20 のようなメソッドが含まれます。

于 2012-07-04T17:36:50.073 に答える