web-dev-qa-db-ja.com

Java EEのファサードのポイントは何ですか？

ファサードのポイントがよくわかりません。

public abstract class AbstractFacade<T> {

    private Class<T> entityClass;

    public AbstractFacade(Class<T> entityClass) {
        this.entityClass = entityClass;
    }

    protected abstract EntityManager getEntityManager();

    public void create(T entity) {
        getEntityManager().persist(entity);
    }

    public void edit(T entity) {
        getEntityManager().merge(entity);
    }

    public void remove(T entity) {
        getEntityManager().remove(getEntityManager().merge(entity));
    }

    public T find(Object id) {
        return getEntityManager().find(entityClass, id);
    }

    public List<T> findAll() {
        CriteriaQuery cq = getEntityManager().getCriteriaBuilder().createQuery();
        cq.select(cq.from(entityClass));
        return getEntityManager().createQuery(cq).getResultList();
    }

    public List<T> findRange(int[] range) {
        CriteriaQuery cq = getEntityManager().getCriteriaBuilder().createQuery();
        cq.select(cq.from(entityClass));
        Query q = getEntityManager().createQuery(cq);
        q.setMaxResults(range[1] - range[0]);
        q.setFirstResult(range[0]);
        return q.getResultList();
    }

    public int count() {
        CriteriaQuery cq = getEntityManager().getCriteriaBuilder().createQuery();
        Root<T> rt = cq.from(entityClass);
        cq.select(getEntityManager().getCriteriaBuilder().count(rt));
        Query q = getEntityManager().createQuery(cq);
        return ((Long) q.getSingleResult()).intValue();
    }
}

このコードがあり、次にこのようなEJBがある場合。

@Stateless
public class WrapSpecFacade extends AbstractFacade<WrapSpec> {
    @PersistenceContext
    private EntityManager em;

    @Override
    protected EntityManager getEntityManager() {
        return em;
    }

    public WrapSpecFacade() {
        super(WrapSpec.class);
    }

}

これのポイントは何ですか？なぜこれをファサードと呼ぶのですか？私にとっては、同様の機能をグループ化するのは単なる抽象クラスです。ありがとう。

javadesign-patternsjakarta-eeejbfacade
17
Drew H

ファサードはデザインパターンです。パターン、ソフトウェアパターンは、コードを整理し、特定の構造を提供するための一連のルールです。パターンを使用することで、いくつかの目標を達成できます。アプリケーションを設計するときは、デザインパターンが使用されます。

ファサードパターンを使用すると、プログラマーはオブジェクトが他のオブジェクトを使用するためのシンプルなインターフェイスを作成できます。非常に複雑なクラスのグループを操作することを検討してください。すべてが独自のインターフェイスを実装しています。さて、あなたはあなたが持っている多くの機能のいくつかの機能だけを公開するためのインターフェースを提供したいと思います。そうすることで、コードの単純さ、柔軟性、統合、疎結合を実現します。

あなたの例では、ファサードは多くのアクター間の結合を管理するために使用されます。これは設計上の問題です。多くのコンポーネントが相互作用している場合、それらが結び付けられるほど、それらを維持するのが難しくなります（つまりコードの維持）。ファサードを使用すると、疎結合に到達できます。これは、プログラマーが常に到達しようとする目標です。

次のことを考慮してください。

public class MyClass1 implements Interface1 {
   public void call1() {}
   public call call2() {}
}

public class MyClass2 implements Interface2 {
   public void call3() {}
   public void call4() {}
}

public class MyClass {
   private MyClass1 a;
   private MyClass2 b;
   //calling methods call1 call2 call3 and call4 in other methods of this class
   ...
   ...
}

Call1またはcall2 ...で使用されるクラスにあるビジネスロジックを、インターフェイスを変更せずに変更する必要がある場合は、これらすべてのクラスを変更する必要はありませんが、のインターフェイスメソッドの1つで使用されるメソッド内のクラスのみを変更する必要があります。最初の2つのクラス。

ファサードを使用すると、このメカニズムを改善できます。

申し訳ありませんが、あまり見栄えが良くないことに気づきました。デザインパターンはソフトウェア業界で頻繁に使用されており、大規模なプロジェクトで作業するときに非常に役立ちます。プロジェクトはそれほど大きくなく、それは本当かもしれないと指摘するかもしれませんが、Java EEは、ビジネスおよびエンタープライズレベルのアプリケーションプログラミングを支援することを目的としています。そのため、デフォルトでファサードパターンが使用されることがあります。 （一部のIDEもそれを使用します）。

17
Andry

通常、このパターンは、インターフェイスを提示している基礎となるクラスの実装を非表示にするか、複雑な可能性のあるものの基礎となる実装を単純化するために使用されます。

ファサードは外の世界へのシンプルなインターフェースを提供するかもしれませんが、内部では、他のクラスのインスタンスの作成、トランザクションの管理、ファイルまたはTCP/IP接続の処理などを行います。これらはすべてシンプルなインターフェースで保護できます。

8
Griff

あなたの特定の文脈では、これは実際にはファサードではありません。そのコードに含まれているのは、基本的にDAO（データアクセスオブジェクト）です。

DAOはDB操作のファサードと見なすことができますが、これはその主な目的ではありません。主にDB内部を非表示にすることを目的としています。この例では、基盤となるストレージシステムをXMLファイルまたはHBaseなどのキー値ストアに切り替える場合でも、その「ファサード」で定義されているメソッドを使用でき、クライアントコードを変更する必要はありません。

（従来の）ファサードは、クライアントから隠す必要のある複雑なデザインを扱います。複雑なAPIと複雑なフローを公開する代わりに（このサービスからこれを取得し、このコンバーターに渡し、結果を取得してこれで検証してから、この他のサービスに送信します）、すべてをファサードにカプセル化するだけです。簡単なメソッドをクライアントに公開します。このように、APIがはるかに使いやすいという事実に加えて、クライアントコードを壊すことなく、基盤となる（複雑な）実装を自由に変更することもできます。

7
Costi Ciudatu