Java EE 6 を使用して Web アプリケーションを開発しています。データベースへの呼び出しを最小限に抑えるには、次のクラスを用意することをお勧めします。
データ アクセス クラス (DAO) は、基本的なメソッドgetAllClients, getAllProducts, getAllOrders, delete, updateメソッド (CRUD メソッド) のみを呼び出します。
CRUD メソッドを呼び出すサービス クラスに加えfindClientByName, findProuctByType, findProductByYear, findOrderFullyPaid/NotPaidて、基本的な DAO メソッドに基づくフィルター メソッドなど。
ありがとうございました
私の経験では (制限はありますが)、DAOクラスには、アプリケーションが実行できるすべての可能なデータベース操作が含まれる傾向があります。したがって、あなたの場合、getAllClients()やなどのメソッドがありますgetClientByName(String name)。
DAO 内のすべてのユーザーを取得し、必要なユーザーが見つかるまですべてのユーザーを反復処理すると、計算時間とメモリ消費が不必要に無駄になります。
データベースがヒットする回数を減らしたい場合は、キャッシング メカニズムを実装することもできます。ここに示すように、 HibernateなどのORMフレームワークは、必要なものを提供できるはずです。
編集：
コメントの質問によると、いいえ、サービスが冗長になることはありません。通常、Serviceレイヤーを使用して機能を公開しDAOます。これにより、基本的に、DAOアプリケーションのフロントエンドからは見えなくなります。通常、たとえば などの追加のメソッドも使用できますpublic String getUserFormatted(String userName)。これgetUserByNameにより、DAOが提供する機能が利用されますが、いくつかの追加機能が提供されます。
Service仕様に変更があり、アプリケーションとインターフェースするための Web サービスも必要になった場合、このレイヤーはそれ自体も有用になります。間にサービス レイヤーを配置すると、Web サービスはレイヤーDAOを介してクエリを実行できますService。
したがって、基本的に、サービスがDAOを公開せずに返されたデータを適応させている間、DAOレイヤーはデータベースのもの（CRUD操作）を心配します。DAO
詳細な情報がなければなんとも言えませんが、CRUD 操作だけでなく、データベースをさらに活用することをお勧めします。データベースは、正しく構成されていれば検索が得意です。そのため、find メソッドでデータベースに検索を処理させることをお勧めします。これは、find メソッドがおそらく DAO に含まれることを意味します...
DB アクセスがパフォーマンスに与える影響について考えたり認識したりするのは良いことですが、行き過ぎないようにしてください。また、あなたのアプローチは、サービスがフィルタリングを行うため、大量の DB データをアプリケーションにロードすることを意味しますが、これは悪い考えです。肝心なのは、RDBMS の使用を意図したとおりに使用し、問題を示すことができる場合は過剰アクセスによるパフォーマンスを心配する必要があるということです。あなたがそのシナリオに遭遇することはないと思います。
DAO を指定したよりも細かくした方がよいと思います。
データベースはメモリ内コードよりもデータのフィルタリングとソートに優れている可能性が高いため、何らかの方法で findClientByName、findProuctByType、findProductByYear、findOrderFullyPaid/NotPaid を DAO に配置することをお勧めします。
10 年分のデータがあり、サービス クラスで findProductsByYear を呼び出すと、getAllProducts が呼び出されて、メモリ内の 9 年分のデータが破棄されるとします。興味のある年だけをデータベースに返してもらう方がはるかに良いでしょう。
はい、これが正しい方法です。
サービスはトランザクションを所有します。これらは POJO として記述する必要があります。そうすることで、それらを SOAO または REST Web サービス、EJB、または後で必要なその他のものとして公開できます。