JPAなど、DAOパターンを推奨しないことがわかりました
JPAなど、DAOパターンを推奨しないことがわかりました。わかりませんが、特にサーバー管理のJTAマネージャーの場合はそう感じます。
DAOパターンを適切に実践した後、そのパターンを中心にJPAベースのアプリケーションの設計を開始しました。しかし、それは収まりません、IMO。私はJPAとすべての機能をかなり失う傾向があります。
さて、悲観的なロックを使用してクエリを実行し、DAOメソッドからエンティティのリストを返したとします。戻ると、トランザクションは終了し、ロックは解除されます（サーバー管理のJTAマネージャーの場合）。だから、大まかに言えば、意味がありません。ただし、有効なケースがあります。
別の例ははるかに些細なことです。クエリを実行して、他のエンティティとの遅延読み込みの1対多の関連付けを持つエンティティを取得するとします。 DAOメソッドを返すと、トランザクションは終了します。遅延読み込みは機能しなくなり、nullなどを取得するだけです。これに対処するために、手動で熱心にロードします。 a.getBList().size()のようなことをします。
したがって、IMOは、DAOを排他的に作成せず、ビジネスBeanで作成する方が適切です。こうすることで、これらの便利な機能を利用できるようになります。または、ORM APIは、間違いなくDAO /データレイヤー自体と見なすことができます。したがって、別のものを作成する必要はありません。
皆さんはそれについてどう思いますか？
注：DAOパターンが廃止されたとは決して言いません。実際、ケースバイケースです。
単純なアプリケーションの場合、EJBから直接EntityManagerを使用し、DAOパターンをスキップしても問題はありません（コードを書きすぎるのはうんざりです）。そして、これがJPAとJava EE APIが推奨するものです。しかし、より複雑なアプリケーション（ストアドプロシージャ、フラットファイルからのデータアクセスなど）では正当化される可能性があります。 。だからあなたは正しい、それは依存する:)
InfoQの JPAはDAOを殺しましたか？ に他の啓発された視点がありますが、次のように要約できる内容と結論に驚くことはありません：あなたは本当にそうではありません標準のデータアクセスにはDAOパターンが必要ですが、より複雑な状況ではDAOパターンが必要になる場合がありますが、DAOパターンがなくても生活は向上します。
DAO自体をトランザクションとして定義しない場合、これらの問題は発生しません。
トランザクションは複数の操作にまたがることが想定されているため、サービス層はトランザクションであると想定されています。各挿入/更新をトランザクションに入れることは、最善のシナリオではありません。
春を使えば、それを非常に簡単に達成できます。これがないと、DAOにトランザクションロジックを再度含めることができます。つまり、dao.beginTransaction()とdao.commitTransaction()を使用し、代わりにサービスレイヤーから使用します。
私が理解しているように、サービスクラスで直接EntityManagerを使用する方が、ラッパーDAOクラスを使用するよりもおそらく優れているとお勧めします。私は1つの理由で同意しません。サービスクラスでDAOクラス（せいぜいインターフェイス）を使用する場合、JPAAPIにまったく依存しません。 Queryオブジェクトなどを作成する必要はありません。これは大きな利点にはならないかもしれませんが、ベストプラクティスであることに同意するでしょう。また、DAOを変更するだけで、後でプレーンJDBC、プレーンテキスト、XMLなどに切り替えることができます。
これは、別のレイヤーで何かを抽象化する必要がある理由の例として広く使用されていますが、ほとんどの場合、単に過剰設計です。ただし、すべてのデータベースアクセス操作が1つの場所で行われるという事実は、ログ記録、アクセスレベルチェックなどを追加できることを意味する場合があります（はい、DAOがこれを行うのに特に適した方法ではない場合があります）。
したがって、最終的には、要点に戻るには、状況によって異なります。
DAOは設計の観点から使用され、JPAはデータアクセス機能の「公式」ラッパーです。 JPAがDAOを強制終了しようとする方法はありません。DAOの実装が簡単になる可能性があります。おそらく、DAOが非常に単純に見えるため、無視できます。しかし、DAOレイヤーがなければ、設計上のメリットはありません。
もちろん、「単純な」プロジェクトの場合は無視できます。プロジェクトが十分に「単純」である場合、多くのことが「無視」される可能性があります。