問題タブ [genericdao]

私はこのアーキテクチャを行うことを考えています

genericdao + interface ---> servicelayer + interface ---> view layer

私のdaoには一般的なメソッドしかなく、たとえばサービスレイヤーには実際のロジックがあります

サービスレイヤー方式

これは良いアーキテクチャですか

私の質問は、「select..」ステートメントをdaoからサービスレイヤーに移動するのに適しているかどうかです。

Javaで汎用DAOを開発しようとしています。私は以下を試しました。これは一般的な DAO を実装する良い方法ですか? 休止状態を使用したくありません。同じコードを何度も繰り返す必要がないように、できるだけ汎用的にしようとしています。

今私が持っています：

私はこの記事を読みました：

http://www.ibm.com/developerworks/java/library/j-genericdao.html

何度か言って、それが言っていることを理解していると信じています。ただし、それは 4 年前のものであり、私は JPA 準拠の Java アプリケーションと競合する必要があります。さらに、Spring にはいくつかの優れた機能を備えた JPATemplate があることがわかりましたが、Spring のドキュメントによると、それは既に非推奨になっています。

ジェネリックファインダーの実行を提供するためにインターフェイスをプロキシする GenericDAOImpl の、堅牢で最新の、JPA 準拠の、Spring ベースの実用的な例を誰かに教えてもらえますか?

私はsqlalchemyでパイロンを使用しています。私にはいくつかのモデルがあり、そのようなコードを何度も書いていることに気付きました。

モデルはすべてextend classBaseであるため、共通のメソッドを定義する方法はありますget_by_id()か?

だから私はそれを次のように使うことができます：

私はこれが非常に頻繁に尋ねられることを知っています、しかし私は実用的な解決策を見つけることができません：

これは私のAbstractDAOです：

そして、これは私のJPAの実装です。

そしてこれは1つのエンティティのdaoです：

その実装は次のとおりです。

アーキテクチャ全体は単純です：

インターフェイスAbstractDaoは、単純なCRUDメソッドを定義します。

インターフェイスPersonDaoは、アドオンメソッドなしでAbstractDAOを拡張します。

クラスAbstractDaoJpaImplは、JPAによるAbstractDaoの実装を定義します。

クラスPersonDaoImplは、AbstractDaoJpaImplを拡張し、aditionalMethods （）を追加するPersonDaoANDOtherInterfaceを実装します。

、PersonDaoImplはPersonDaoのみを実装し、OtherInterface.additionalMethods（）を実装しない場合、すべてが正常に機能します。

使うことができます

私の春のXMLファイルで。

しかし、PersonDaoImplはOtherInterfaceを実装します。テスト/実行するとき、DAOをPersonDaoからPersonDaoImplまたはOtherInterfacesにキャストする必要があります。

この問題は(PersonDaoImpl) dao、「プロキシをPersonDaoImplにキャストできません」という例外をスローする場合に発生します。

これはグーグルするときによく聞かれます、誰もがに追加proxy-target-class="true"することを提案し<tx:annotation-driven>ます：

これにより、JDKの動的プロキシの代わりにCGLIBが使用されます。

しかし、Springを初期化するときに別の例外をスローします：

AbstractDaoJpaImplのコンストラクター：

すべての質問はここで止まります、私は今、実用的な解決策を見つけることができません。

誰かが私に実用的な解決策を与えることができますか？どうもありがとう ！

環境：Spring-3.0.4、javaee-api-6.0、javax.inject、cglib-2.2、hibernate-jpa-2.0-api-1.0.0、

前の質問であるDAOおよびサービスレイヤー（JPA / Hibernate + Spring）に続いて、JPA / Hibernate、Spring、およびWicketを使用するアプリケーションでは、データレイヤーに（少なくとも最初は）単一のDAOのみを使用することにしました。一般的なCRUDメソッドの使用が提案されましたが、JPAを使用してこれを実装する方法がよくわかりません。例を教えてください、またはこれに関するリンクを共有してください。

私は問題があります。私は親DAOを持っています:

そこから別の子 DAO を拡張します。子 DAO で子エンティティを操作したい場合、親クラスから EntityManager オブジェクトを取得するか、entityManager オブジェクトの宣言を protected に変更する必要がありますが、これは不適切な OOP 設計です。これを行う別の方法はありますか？100 個の DAO の子がある場合、新しい子ごとに親 DAO から entityManager を取得する必要があるためです。

私は小さな素敵な JavaSE/Guice の世界から来たばかりで、現在「コンテナによって運ばれる」EE6 の道を発見しています。Glassfish3.1 で問題が発生した後、JBoss に切り替えたところ、問題が発生するはずがありません。

インフラ支援クラスとして、あらゆる種類のエンティティ用の汎用リポジトリ/DAO を作成しようとしています。非常に単純な方法で、これは次のようになります。

現在、エンティティ依存のクエリ機能を必要とせず、次のような特定のエンティティ タイプのリポジトリのみを必要とする Bean が存在する場合があります (テスト ケースである可能性があります)。

残念ながら、Weld はこの種のジェネリック インジェクションを好まないようです。展開時に、次のエラーが発生します。

私は何かを見逃していますか、それともジェネリック注入を実装するのを忘れていましたか? 私が一般的なものを理解している限り、それはとにかくコンパイル時に消去されます - これは今のところ guice3 でとてもうまくいきました。

敬具、

アビ

編集：この動作は仕様にあるが、溶接には実装されていないというガービン・キングのコメントを見つけました（声明は2009年6月にありました）

String フィールドに格納されている型に基づいてエンティティ オブジェクトを作成する単純な DAO を作成しようとしています。動的に変更された型を返す方法は? UserDAO クラスのメソッド findById() は User クラス オブジェクトを返す必要があります。ProductDAO の同じメソッドは Product を返す必要があります。DAO を拡張するすべてのクラスに findById を実装したくありません。自動的に実装する必要があります。

コード例:

次のようなDAOインフラストラクチャがあります。

StoreDao、CouponDao、PersonDao .

これらはすべて、(Java Generics を使用して) 機能の大部分を備えたGenericDaoから拡張されています。ここで説明されている種類 - [http://www.ibm.com/developerworks/java/library/j-genericdao/index.html][1]

getAll() が StoreDao で呼び出されると、実際に呼び出されるのは GenericDao の getAll() であり、active=true、expires>now() などの特定のデフォルトの where 句を実行される既存の HQL クエリに追加します。

setup() でデータを作成する一連の Dao テストがあり、応答でアサートする一連のテストがあります。データベースはモックされていないため、正確には単体テストではありませんが、統合テストと呼ぶことができます。

私のチーム メイトの 1 人が、生成された SQL クエリが正確かどうかをテストするためのテスト インフラストラクチャを作成しました。彼がこれを行う方法は次のとおりです。

onPrepareStatement() をインターセプトするカスタム Hibernate インターセプターを用意し、Hibernate の ASTParser を使用して実行しようとしているクエリの XML 構造を作成し、XPath を使用してクエリを検証します。結合が正しいなど。

これは、Generic Dao を単独でテストするために行っています。このために、GenericDomain、GenericChildDomain、GenericDomain.hbm.xml を、これらをサポートするテーブルと共に作成する必要があります。

質問:

これは価値がありますか？すでに持っているすべての単体テストのデータベースを完全にモックアウトしない限り、このインフラストラクチャを作成する理由はわかりません。

既存のインフラストラクチャで HQL をテストできないわけがありません。active=true がクエリに追加されたことを確認したい場合は、DAO が active=false でデータを返さないことを確認してください。

最後に、ここで行っているのは休止状態に特化したものであり、DAO を IBatis/JPA-EclipseLink/NoSQL などに置き換えることにした場合、ほとんどが破棄されます。

最後に、なぜこのようなものを発明しなければならないのでしょうか。これはかなり一般的な問題ではありませんか？誰かによってすでに構築されたソリューションはありませんか？