私はSpringMVC、Hibernate、およびJava Webアプリケーションの例でいくつかのデータベースを使用しています。
これを行ういくつかの異なる方法がありますが、このSpring 3とhibernateの統合チュートリアルの例には、モデルクラス、ビュー（jsp内）、およびコントローラーのサービスクラスとdaoクラスがあります。
私の質問は、サービスとDAOクラスの両方が同じことをしないのですか？なぜ両方が必要なのですか？
これは私が実際に使用していたチュートリアルです：http : //fruzenshtein.com/spring-mvc-security-mysql-hibernate/
回答:
一般に、DAOは可能な限り軽量で、DBへの接続を提供するためだけに存在します。異なるDBバックエンドを使用できるように抽象化されることもあります。
サービス層は、DAOおよびクライアントとの間で送受信されるデータを操作するロジックを提供するためにあります。多くの場合、これら2つの部分は同じモジュールにバンドルされ、場合によっては同じコードにバンドルされますが、それらは別個の論理エンティティとして表示されます。
もう1つの理由はセキュリティです。DBとは関係のないサービスレイヤーを提供する場合、サービス以外を介してクライアントからDBにアクセスすることはより困難になります。DBがクライアントから直接アクセスできない場合（およびサービスとして動作する些細なDAOモジュールがない場合）、クライアントを引き継いだ攻撃者ができることは、サービスレイヤーをハッキングすることだけです。データへの最も衛生的なアクセス。
私は問題の投稿の作家です。私は、さまざまなテクノロジーとさまざまなアーキテクチャに取り組んでいます。上記に基づいて、サービス層とdao層を持つことは常に良い考えだと安全に言うことができます。DAOは、データベースへの/からのエンティティオブジェクトの追加/更新/挿入/選択のみに制限する必要があります。ロジックに関して特別なことをしたい場合は、サービスレイヤーに追加します。これは、コードをモジュール化し、データベースを（データの一部について）交換するときに簡単に交換できるようにするのに役立ちます。これは、データベースからデータをフェッチした後でも重いロジックを持つレポートを含むアプリケーションに特に適用されます。
また、春には、セキュリティがサービス層で理想的に適用されます。このように変更したくないでしょう。
Adam Bienは、彼の本の中で、JPA EntityManagerがDAOの優れた普遍的な実装であるという事実を指摘しています。
Java EEの世界では、JPAの実装にDAOが含まれているため、独自のDAOを作成する必要はほとんどありません。サービスレイヤーを記述するだけです。
独自のDAOレイヤーを実装することは、15年前の非常に貧弱なJ2EEアーキテクチャからの二日酔いに過ぎませんが、多くの人々はそれを行うことを余儀なくされています。多くの場合、これらのカスタムDAOレイヤーは、EntityManagerで対応するメソッドを呼び出す転送機能以外のものを提供しません。
したがって、質問に答えるには、はい、サービスレイヤーとDAOが必要ですが、サービスレイヤーを記述するだけです。
ほとんどの場合、サービス層が不必要な複雑さを追加することがわかりました。理論的には、ビジネスロジックをdaoレイヤーに配置することを避けることですが、最終的にこれは混乱を招くだけです。http://ayende.com/blog/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer
しかし、複数のビジネスロジックがある場合は、はい、それは良い考えです。 サービス層を作成することはどれほど重要ですか？
IMHOサービス層は、コントローラーとDAO層の間の層と考えることができます。このサービスレイヤーは、ビジネスロジックを追加したり、ビューでレンダリングする必要のあるものに固有の戻りオブジェクトを作成したりできる場所です。