我对Spring和Hibernate还不熟悉，正试图学习j2ee应用程序的最佳实践和设计方法。
我已经成功创建了一个基本的Spring MVC Web应用程序，现在正在寻找以下内容：
如果有关于使用Spring Hibernate设计良好Web应用程序的参考资料，将不胜感激；）
谢谢
您必须使用服务bean。服务逻辑应该只在那里。
DAO应该仅用于与数据库相关的操作。
现在，您可以在服务bean中注入多个DAO。
FWIW - 我刚刚经历了类似的学习过程，学习Spring。好消息是，谷歌上有很多示例；坏消息是，没有很多适合新手的“完整”示例（而且如果你要针对v3 Spring，那里面有很多基于新基线的混淆内容）。对我有用的是以下内容：从SpringSource网站上的示例应用程序开始（http://www.springsource.org/documentation）。在他们的少数几个示例之间，几乎包含了你需要的所有组件，至少是最小形式。当我在这些示例中发现需要的内容时，我会根据类似的术语（一些@注释等）进行谷歌搜索，以找到更完整的信息/更好的示例。其中许多搜索结果又将我带回到这个网站，这就是为什么我开始频繁访问这里-已经有很多好问题得到了解答。我想这不是一个过于深入的答案，但这个过程让我在相当短的时间内掌握了基础知识。
DAO层和Service层是不同的实体：
DAO负责从数据库中获取和放置单个对象。例如，从数据库中获取用户（id，name，lastname）。
Service层负责你的业务逻辑。它可以使用多个DAO对象来执行一个动作。例如，从一个用户发送消息到另一个用户，并将其保存到第一个用户的已发送文件夹和收件人的收件箱中。
服务是关于向用户提供一个外观，以展示用户可以执行的业务功能。基本上，如果您有一组低级用例，服务上的方法将与单个用户操作相对应。服务是事务性的，通常情况下，如果用户做了什么，我们希望所有这些动作的后果都能够一起提交。控制器和服务之间的分离意味着我们有一个地方来放置Web应用程序特定的功能，例如获取请求参数，进行验证，并选择要转发或重定向的位置，并且还有一个单独的地方来放置业务逻辑，这些逻辑与Web应用程序API无关，与使用哪些数据访问对象更新哪些值以及使用哪些数据访问对象持久化相关的对象有关。
我看到很多人似乎认为每个DAO都需要一个服务。我认为他们的假设是因为数据访问对象、控制器和模型在定义上都相当机械化，所以服务也必须是这样，他们构建服务时没有考虑正在实现的用例。结果是，除了有很多无用的服务样板代码外，所有业务逻辑都混杂在控制器中与特定于Web的代码混在一起，控制器变得庞大且难以管理。如果您的应用程序非常简单，您可以暂时使用它，但它是不组织的，难以测试，通常是一个坏主意。关注点分离，将基础架构代码放在一个地方，将业务代码放在另一个地方，这是我们应该追求的目标，并且正确使用服务对于实现这一目标非常有帮助。