0

重複していたらごめんなさい。

ビジネス層で ID の代わりにオブジェクトを使用することは可能ですか、または推奨されますか?

SELECT c
FROM Child AS c
WHERE c.parent = :parent

public List<Child> list(final Parent parent) {

    // does parent must be managed?
    // how can I know that?
    // have parent even been persisted?

    return em.createNamedQuery(...).
        setParameter("parent", parent);
}

これが私が働く方法です。

SELECT c
FROM Child AS c
WHERE c.parent.id = :parent_id

public List<Child> list(final Parent parent) {

    // wait! parent.id could be null!
    // it may haven't been persisted yet!

    return list(parent.getId());
}

public List<Child> list(final long parentId) {
    return em.createNamedQuery(...).
        setParameter("parent_id", parentId);
}

更新された質問 --------------------------------------

それぞれに注入できる JAX-RS または JAX-WS クラス@EJBは、同じ JTA で言うことができますか?

ここで、私がいつも気になっている非常に独創的な問題が発生します。

2 つの EJB があるとします。

@Stateless
class ParentBean {

    public Parent find(...) {
    }
}

@Stateless
class ChildBean {

    public List<Child> list(final Parent parent) {
    }

    public List<Child> list(final long parentId) {
    }
}

EJB クライアントを処理する適切な方法は何ですか?

@Stateless // <<-- This is mandatory for being injected with @EJB, right?
@Path("/parents/{parent_id: \\d+}/children")
class ChildsResource {

    @GET
    @Path
    public Response list(@PathParam("parent_id") final long parentId) {

        // do i just have to stick to this approach?
        final List<Child> children1 = childBean.list(parentId);

        // is this parent managed?
        // is it ok to pass to other EJB?
        final Parent parent = parentBean.find(parentId);

        // is this gonna work?
        final List<Child> children2 = childBean.list(parent);

        ...
    }

    @EJB
    private ParentBean parentBean;

    @EJB
    private ChildBean childBean;
}
4

2 に答える 2

2

以下は、残念ながら2番目の質問「それぞれが可能なJAX-RSまたはJAX-WSクラスを実行する」を完全に理解していないため、「ビジネスレイヤーがIDの代わりにオブジェクトを使用することは可能または推奨されますか？」という質問に対する回答としてのみ提示されます。 @EJBを注入することは、同じJTAで言うことができますか？」

可能です。ほとんどの場合、これもお勧めします。ORMの全体的な目的は、データベースでのオブジェクトの表示ではなく、オブジェクトとその関係を操作できることです。

エンティティのID（特にサロゲートIDの場合）は、多くの場合、ストレージ自体の近くにいる場合にのみ興味深い概念です。提供された永続性のみがidにアクセスする必要がある場合、idにアクセスするメソッドを設計することはしばしば理にかなっていますprotected。そうすることで、エンティティのユーザーに公開されるノイズが少なくなります。

通常どおり、有効な例外もあります。たとえば、エンティティ全体をネットワーク上で移動するのはリソースを消費しすぎるため、エンティティのリストではなくIDのリストを使用することをお勧めします。このような設計上の決定は、問題が実際に発生する前に行われるべきではありません。

于 2012-07-23T07:14:38.860 に答える
1

親がまだ永続化されていない場合、クエリは機能せず、それを実行してもあまり意味がありません。親が永続化されていない場合は、実行を回避するのはあなたの責任です。しかし、私はそれをfindメソッド自体の責任にはしません。メソッドのドキュメントで、引数として渡される親がIDを持っているか、少なくとも永続的である必要があることを明確にしてください。エンティティマネージャーと同じ検証を行う必要はありません。

永続化されているがフラッシュがまだ行われていない場合、エンティティマネージャーは、クエリを実行する前にフラッシュする必要があります。これにより、クエリで新しい親の子が検出されます。

少なくともHibernateでは、切り離された親を使用してクエリを実行できます。IDが存在する場合、クエリはそれを使用してクエリを実行します。

于 2012-07-23T07:20:50.660 に答える