14

EJB セッション Bean にアクセスするときに Facade パターンを使用する理由をお聞きしたいです。私の Netbeans 6.9.1 では、New>を実行し、エンティティSessions Bean for Entity Classesを選択Userすると、Netbeans はこのコードを生成します。

AbstractFacade.java
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 T edit(T entity) {
        return 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() {
        javax.persistence.criteria.CriteriaQuery cq = getEntityManager().getCriteriaBuilder().createQuery();
        cq.select(cq.from(entityClass));
        return getEntityManager().createQuery(cq).getResultList();
    }

    public List<T> findRange(int[] range) {
        ...
    }

    public int count() {
        ...
    }

と

UserFacade.java    

package com.bridgeye.ejb;

import javax.ejb.Stateless;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;

@Stateless
public class UserFacade extends AbstractFacade<User> {
    @PersistenceContext(unitName = "Bridgeye2-ejbPU")
    private EntityManager em;

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

    public UserFacade() {
        super(User.class);
    }        
}

これの利点は何かと聞きたいです。10 個のエンティティがある場合、Netbeans は 10 個の Facade クラスと AbstractFacade を生成します。これは私にはやり過ぎのようです。マネージド Bean 内のどこかで、これを行う必要がpersistあるUserとしましょう。School

someManagedBean.java

...
@EJB
private UserFacade userEJB;

@EJB
private SchoolFacade schoolEJB;

...

public void someMethod(User user, School school){
    ...
    userEJB.create(user);
    schoolEJB.create(school);    
}

これは正しいことですか？

4

3 に答える 3

24

EJB を使用するポイントは、宣言型トランザクションやアノテーション (または XML 構成) によるセキュリティなどの機能を提供することです。これらの機能を使用しない場合、EJB を使用しても意味がありません。

さらに、その自動生成されたファサード コードは、出発点 (および悪い点) です。EJB は、すべての個々の CRUD 操作のラッパーではなく、ドメイン API を形成する必要があります。それらには、ドメイン モデルで実際に実行したい操作のみを含める必要があり、その多くは、トランザクション内で実行する必要がある複数の CRUD 操作にまたがる必要があります。例えば：

@TransactionAttribute
public void transferUser(User u, School from, School to){
    from.getUsers().remove(u);
    to.getUsers().add(u);
    u.setSchool(to);
    getEntityManager().merge(from);
    getEntityManager().merge(to);
    getEntityManager().merge(u);
}

アプリサーバーはトランザクション内のすべての操作を実行します。これにより、たとえば、何らかの理由で例外がスローされ、ユーザーが一方の Schoold から削除されたが、もう一方の Schoold には追加されないという状況が発生しないことが保証されます。 .

于 2011-04-12T14:42:34.317 に答える
7

はいといいえ。ファサード パターンは非常に理にかなっていますが、ドメイン オブジェクトごとに個別のフェースを持つことは意味がありません。

ドメイン オブジェクトの機能のグループごとにファサードをグループ化する必要があります。課金システムを想像してみてください。請求書、アイテム、顧客、住所があります。したがって、請求処理 (アイテムの追加、顧客の設定、印刷、支払済としてのマーク) のための Facade と、ユーザーの作成と更新、住所との関連付けなどのための別の Facade があるでしょう。

于 2011-04-12T14:32:16.500 に答える
1

ご覧のとおり、典型的な CRUD 操作には 1 つの AbstractFacade が必要であり、特定のエンティティを操作するには多くの SpecificFacade が必要だと思います。したがって、同じ基本ロジックを 1 回だけ何度も再実装することはできず、エンティティに関連付けられたより複雑なロジック (トランザクション) のみに集中できます。

于 2015-07-11T15:36:04.380 に答える