2009-07-07 2 views
0

MVCを理解しているように、モデルのロジックもモデル自体に入り、すべてのオブジェクトを自己エンティティにする必要があります。これは、クラスのメソッドがトリガーと一連のアクションを持たなければならないことを意味します。たとえば、PersonクラスでsetZipCode(zip)を使用すると、zipからcityテーブルへの郵便番号を検索し、setCity(city)を同じに設定するアクションがトリガされます。JPAを使用するときにMVCを実装する

これはすべて素晴らしく思われますが、JPAの実装を写真に取り込むとどうなりますか?私が見てきたように、クラスのセッターとゲッターは、JPA実装がこれらを使ってオブジェクトを構築するので、余分なロジックをすべて除去しなければなりません。したがって、setZipCode内でsetCityを呼び出すことはできません。私たちは、モデル固有のすべてのロジックをコントローラレイヤーに移動することで、私が作業するプロジェクトです。この場合Personを直接呼び出すのではなく、両方を処理するPersonController.setAddressInfo(zip)を呼び出すか、またはこのようなものを呼び出します。おそらく、より良い選択肢は、これを行うエンティティ自体の中に一時的な機能を持たせることでしょう。

これは私の質問です:私はMVCやJPAの原点に欠かせないものを持っているのですか、MVCはORMレイヤーを使用すると完全に実装できないのですか?ジェネリックセッターとゲッターがJPAのために非公開で、クラスは開発者向けの公開された一時的なAPIを持っている方が良いでしょうか? (Hibernateはなんらかの理由でプライベートメソッドにアクセスする気にはならないようです)。プロジェクトでHibernateを使用するJPA実装のうち、私の同僚は別のプロジェクトでEclipseLinkを使用しています。私はOpenJPA最近、

答えて

2

実際のJPAドメインオブジェクトとMVCフレームワークコントローラの間に別のレイヤーを追加する必要があるかもしれないという経験をしました。 JPAについての文献は、データアクセスオブジェクト(DAOを)は理想的には、JPAのビジネス・オブジェクトはただのPOJO(Plain Old Java Objects)ですそれらを呼び出す任意のロジックを持っているとのDAOは

List<Post> PostDao::searchPostsByDate(Date d); 
void PostDao::save(Post p); 

のような操作を実装していないゲッターとセッターを持ちますDAOが1つのドメインモデルエンティティに固有で、サービスクラスがトランザクション管理を行い、対応するDAOメソッドを呼び出すDAOレイヤの上に別のサービスレイヤーがあったアーキテクチャでも作業しました。サービスは

City MainService::getCityByZipCode(ZipCode zc); 

個人的に私がしたとき、例えば、サービス層は必須ではないと思われるような方法を提供することができるように、これらのサービスは、いくつかのDAOと相互作用することができますあなたのDAOでスプリングス@Transactionalアノテーションを使用して(私はトランザクションとすべてのものを制御し、他のビジネス・オブジェクトを呼び出して、ビジネス層、および値の層にモデルを分離するために使用

@Transactional 
City ZipCodeDAO::getCity(ZipCode z); 
0

のように薄く、適切な方法を提供しますPOJO)。

ORMは、MVCパラダイムを損なうことなく、ビジネスレイヤとうまく統合できます。

JPAバージョンは前述のとおり動作します。

よろしくお願いいたします。

関連する問題