0

私の同僚は、EJB 自体にメソッドの実装を含めるべきではなく、メソッド呼び出しをいくつかの「ヘルパー」クラスに委譲するだけでよい、つまり、EJB メソッドは次のようにする必要があると言いました。

public String bsuinessMethod1() {
   return helper.bsuinessMethod1()
}

public void bsuinessMethod2() {
   helper.bsuinessMethod2()
}

上記のようにメソッドをデリゲートする理由は、コードの結合を少なくするためです (たとえば、EJB コンテキストではない「ヘルパー」クラスのメソッドを再利用したい場合)。また、彼は、ビジネス メソッドは Java EE について何も知らなくてもよいと述べました。

(上記のステートメントが間違っている場合は訂正してください。JPA トランザクションは使用しないことに注意してください。データの永続性を処理するために別のフレームワークを使用します)

したがって、上記の記述が正しければ、私の「ヘルパー」クラスには EJB と同じメソッドが必要です。では、ヘルパー クラスに EJB インターフェイスを再利用できますか (つまり、ヘルパー クラスを作成して、EJB と同じインターフェイスを実装します)。建築的な観点からは悪くないでしょうか？

4

2 に答える 2

1

私の同僚は、EJB自体にはメソッドの実装を含めるべきではなく、メソッド呼び出しをいくつかの「ヘルパー」クラスに委任するだけでよいと言っていました。

私はあなたがそれから多くの利益を得るとは思わない。ビジネスロジックをEJBに直接配置してみませんか？正直なところ、マイナス面は見当たりません。

そして、上記のようなメソッドを委任する理由は、結合されたコードを少なくするためです（たとえば、EJBコンテキストではない「ヘルパー」クラスのメソッドを再利用したい場合）

クラスを分離して、ヘルパークラスに委任するだけでなくEJBを使用することもできます。デカップリングは、ヘルパークラスへの委任よりも、プログラムからインターフェイスへの依存性注入と依存性注入の使用に依存します。

また、彼はビジネスメソッドはJavaEEについて何も知らないはずだと言った。

@Statelessビジネスクラス（EJB）に（Java EEの一部である）注釈を付けると、 JavaEEに依存しなくなります。

したがって、上記のステートメントが正しければ、私の「ヘルパー」クラスはEJBと同じメソッドを持つ必要があります。では、ヘルパークラスにEJBインターフェイスを再利用できますか（つまり、ヘルパークラスを作成してEJBと同じインターフェイスを実装できますか？）建築の観点からは悪いことではないでしょうか。

これは設計の観点からは意味がなく、ヘルパークラスを呼び出すだけのダミーEJBを使用するという点に戻ります。

于 2013-03-02T01:35:58.593 に答える
1

私は思わない

いくつかの「ヘルパー」クラスへのデリゲートメソッド呼び出し

、は、ヘルパークラスを呼び出すだけのejbメソッドを1つのライナーに保つことを意味します。実装をヘルパークラスに委任する目的は、さまざまな種類のサービスエクスポージャー（ejb、pojo、Webサービスなど）によるコア計算を使用することです。これは、サービスをejbから非ejbに簡単に移植するのにも役立ちます。

ヘルパークラスで計算を行うと、必要に応じて複数の方法でサービスを公開するのに役立ちます。それらはすべて、コア計算にこれらのヘルパークラスを使用できます。

たとえば、特定の都市の1日の平均気温を取得するサービスが必要です。例がよく見えない場合はご容赦くださいが、それがアイデアを表現していることを願っています。サービスはする必要があります

  1. その日の特定の都市のデータベースから気温のリストを取得します。（DBでは、40 F、5 Cなどとして保存されます）。
  2. 温度を解析して測定単位を特定し、華氏に変換します。
  3. 無効な温度（無効な文字を含むゼロや値など）をフィルタリングします。
  4. 平均を計算します。

このシナリオでは、項目2、3、および4をヘルパークラスに移動するのが理にかなっています。アイテム1をヘルパークラスに参加させることはお勧めしません。

これで、このヘルパークラスはa）pojoサービスで使用できます。b）ejb。c）Webサービスまたはその他。

于 2013-03-02T03:30:46.760 に答える