タグ付けされた質問 「dao」

3
サービス層はすべてのdao例外をキャッチし、それらをサービス例外としてラップする必要がありますか?
Dao、サービス、コントローラーの3つのレイヤーのSpring Webアプリがあります。コントローラーはdaoを直接呼び出すことはなく、サービス層を介して呼び出します。現時点では、ほとんどの場合、処理されないdao例外(ランタイム)があると、エンドユーザーにエラーメッセージを表示するJSPによってキャッチされます。サービス層はすべてのdao例外をキャッチし、それらをサービス例外としてラップする必要がありますか? try { daoInstance.someDaoMethod(); } catch(DataAccessException dae) { throw new ServiceException("message", dae); } ServiceExceptionもランタイムであり、どちらも処理されないと仮定しましょう。ServiceExceptionの代わりにDataAccessExceptionをスローするだけの違いはありますか?私は、プレゼンテーション層がデータアクセス例外を認識すべきでないと考えました。しかし、単にそれらをラップするだけで回復不能な例外をキャッチするポイントは見当たりません。

3
MVCでは、DAOはコントローラーまたはモデルから呼び出す必要があります
Controllerクラスから直接呼び出されるDAOに対するさまざまな引数と、ModelクラスからのDAOに対するさまざまな引数を見てきました。実際、MVCパターンに従っている場合、コントローラーはDAOと結合するべきではなく、Modelクラス内部からDAOを呼び出し、コントローラーがモデルクラスを呼び出す必要があるのは、なぜWebアプリケーションからモデルクラスを切り離し、RESTサービスがモデルクラスを使用するなどのさまざまな方法で機能を公開できるからです。 コントローラでDAO呼び出しを記述する場合、RESTサービスが機能を再利用することはできません。両方のアプローチを以下にまとめました。 アプローチ#1 public class CustomerController extends HttpServlet { proctected void doPost(....) { Customer customer = new Customer("xxxxx","23",1); new CustomerDAO().save(customer); } } アプローチ#2 public class CustomerController extends HttpServlet { proctected void doPost(....) { Customer customer = new Customer("xxxxx","23",1); customer.save(customer); } } public class Customer { ........... private void save(Customer customer){ …

3
DAOはシングルトンである必要がありますか?
RESTful APIを開発しており、リソースにDAOを使用すると便利だと思います。メモリを使用してそれらを格納するだけですが、使用することに決めた場合はライブラリを使用しているユーザーのドアを閉めたくないためです。 DAOのデータベース実装。 私の質問は、DAOがシングルトンであるかどうかです。そうでない場合、サービスにはDAOのインスタンスがあり、おおよそ次のようになります。 @Path("eventscheduler") public class EventSchedulerService { private IEventSchedulerDao dao = new EventSchedulerDao(); // in case a different implementation is to be used public void setEventSchedulerDao(IEventSchedulerDao dao) { this.dao = dao; } @Path("{uniqueName}") @GET @Produces(MediaType.APPLICATION_JSON) public Tournament getTournament(@PathParam("name") String uniqueName) { return dao.get(uniqueName); } @Path("create") @POST @Consumes(MediaType.APPLICATION_JSON) @Produces(MediaType.APPLICATION_JSON) …

3
1つのトランザクションで2つのDAOメソッドを管理する方法は?
インタビューで誰かが私に尋ねました:単一のトランザクションで2つのトランザクション/ダオ方法をどのように管理しますか。必要な機能: それらのいずれかが失敗した場合、両方の方法をロールバックする必要があります。 両方のメソッドは、単一のトランザクションで個別に接続して呼び出すことができます。 管理は、サービス層ではなくDAO層で行う必要があります。 私は思う:質問は春のトランザクション管理に関連しています。

2
リポジトリパターンとDAO管理エンティティ
DAO、DAL、ドメイン駆動設計などのコンセプトは初めてです。最後に、パーシスタンスレイヤー(mysqlデータベース)を、Webアプリケーションのビジネスオブジェクトおよびロジックから切り離したいと考えています。DAOのコンセプトは気に入りましたが、他のエンティティが関連付けられているデータベースからビジネスオブジェクトを作成しようとすると、DAOの実装に行き詰まりました(dbテーブルの外部キーで表されます)。 これらの参照(集計)はDAOパターンを使用してどのように処理されますか?すべてのオンラインDAOの例は単純で、(他のエンティティや値オブジェクトを参照せずに)値オブジェクトのようなビジネスオブジェクトのみの作成を示しています。依存性注入を使用して行われますか?そうであれば、依存関係はどこに作成されますか? さらに読むことで、DDDからのリポジトリパターンは、バックグラウンドでDAOを使用し、オブジェクトの集約を処理する可能性を与えると思います。私が理解しているように、それはいわゆるルート(すべての参照がロードされたエンティティまたはレイジーロードされたエンティティ)を外界に提供するだけです。DAOの使用時にリポジトリは推奨されますか、それともDAO自体がビジネスオブジェクトに対する永続性の無知を維持することによってこの機能を提供できますか? 私はORMツールを使用しておらず、これらの基本的なパターンを直接探求したくはありません。
10 repository  entity  dao 
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.