13

前提

私は最近、Java チャンピオンの Adam Bien による多くの記事/ビデオを読んだり見たりしました。彼は、古いが更新された Entity - Control - Boundary Design Pattern JAVA EE >= 6 の使用を提唱しています。

CDI、EJB 3.1、JPA 2、およびその他の Java EE 6 機能を活用することで、このパターンは、よりビジネス指向のコンポーネントを作成し、単体テストを容易にし、責任に基づいて関心をより高度に分離するのに役立ちます。

私は上記の機能をすべて使用しており、このパターンは非常に興味深いので、ECB が次のプロジェクトの要件に適合するかどうかを調べています。


これまでに得たもの

ECB では、各論理エンティティは 3 つの部分に分割されます (間違っている場合は訂正してください)。

  • 外部からアクセスできる唯一のクラスである一種の強力なファサードであるBoundary。そして、外側（私が正しく理解した場合）とは、アプリケーションの外側の両方を意味します。リモートクライアント、およびコンポーネントパッケージの外部。私のアプリケーションの別の部分。

  • a(n オプション) Controller、ある種の操作 (エンティティの検証など) を担当します。

  • 純粋なJPA エンティティである可能性があるEntityですが、内部にいくつかの装飾/検証/(最小限の) ビジネスロジックを含めることもできます。

たとえば、2 つの異なるエンティティ (OrangeとApple)、それらに対して CRUD を実行するクラス ( FruitsManager)、およびエンティティに対して何らかの制御を実行するクラス( ) があるとしFruitsQualityCheckerます。

昨日までは、 ( OLD WAY )のようなものでした:

com.foo.bar.business.FruitsService        /* CRUD    */
com.foo.bar.business.FruitsQualityChecker /* CONTROL */
com.foo.bar.model.Orange                  /* ENTITY  */
com.foo.bar.model.Apple                   /* ENTITY  */

一方、ECB では ( NEW WAY ):

com.foo.bar.business.oranges.boundary.Oranges       /* CRUD    */ 
com.foo.bar.business.oranges.control.QualityChecker /* CONTROL */
com.foo.bar.business.oranges.entity.Orange          /* ENTITY  */

com.foo.bar.business.apples.boundary.Apples         /* CRUD    */
com.foo.bar.business.apples.control.QualityChecker  /* CONTROL */
com.foo.bar.business.apples.entity.Apple            /* ENTITY  */

次に、各エンティティを個別にCRUDして調査できます。と

Oranges.findOrangesByPrice(min, max);

主な質問

たとえば、クロスコンポーネントの研究をどのように処理すればよい findFruitsByPrice(min,max)ですか?

findOrangesByPrice結果の両方とfindApplesByPrice合計を呼び出す必要がありますか? どのクラスから、どこにパッケージ化されましたか? また、50 のエンティティにまたがる必要がある、多数の条件を含む検索ページがある場合はどうなるでしょうか。各エンティティの検索メソッドを 50 回実行してから補間を実行すると、パフォーマンスに大きな影響を与える非常に醜い方法のように聞こえます。この種のことを実行するには、まだどこかに中心点が必要だと思います。Searchesその Boundary で他の境界を呼び出すのは、eg と呼ばれる別のコンポーネントである必要がありますか? この点は、ATM にはわかりません。


副次的な質問

アクションベースのフレームワークで ECB を使用することは理にかなっていますか? それとも、このパターンはコンポーネント ベースのフレームワークに追いやられているのでしょうか?

私は MVC アクションベースのフレームワークである Struts2 を使用していますが、MVC コンポーネントベースのフレームワークである JSF2 (JAVA EE 6 標準であり、Adam Bien のショーケースのほとんどで使用されています) にはまったく慣れていません。

アーキテクチャを「コンポーネントの方法」で考えるという追加の努力とは別に、ビジネス層で ECB を使用することを妨げているものはありますか?

Adam Bien の例の境界の大部分は REST サービス (一般に、 「チェーンの新しいギア」というよりも Struts2 アクションの置き換え) であるため、これが Struts2 エコシステムに完全に適しているとは思えません。

あなたのことを言ってください。お願いします。

4

1 に答える 1

4

私がデザインパターンを理解している限り、「これまでに得たもの」は正しいです。

主な質問: 他の設計パターンと同様に、一部のエンドポイントで使用される別の SuperComponent を簡単に導入できます (または、極端に大きくならないように単一のコンポーネントを使用します)。SuperComponent は正しい方法で処理を行います。必要に応じて既存のコンポーネントを使用して、パフォーマンスとコードの品質が低下しないようにします。ここで言いたいのは、おそらく、オレンジとリンゴを返すかどうかを気にしない特定のエンドポイントに関連するロジックを作成し、DB に対して単一のクエリを作成することです (ドメイン モデルがそれを実行できる場合)。他のコンポーネントを使用してそれらの果物を取得し、それらの結合を作成することは、使用するデザイン パターンに関係なく、悪い設計です (画像は後でアボカドを取得し、サポートを得るためにコードを記述したりバグを修正したりする必要があります)。新しい果物）。

副次的な質問( IMHO )に何らかの形で関連しています: ECB は小さなプロジェクトでは問題ありませんが、より大きなプロジェクトでは、おそらくより階層化された構造が必要になるでしょう:

  • HttpRequestリクエスト/ユーザーからの入力を処理するだけの Web レイヤー (EJB がs とsについて知っているという考えは好きではありませんHttpResponse)

  • DAO レイヤーを備えた多層アプリケーション モデル (CRUD 操作には必須ではありませんがNamedQuery、複数の EJB で 5 つのパラメーターを使用して同じものを使用する場合)。

于 2014-11-03T10:28:34.337 に答える