spring mvc dao和服务bean映射

Question

我是Spring和hibernate的新手。 我正试图在j2ee应用程序中学习最佳实践和设计方法。

我有一个设法创建一个基本的春季mvc网络应用程序。现在寻找那 - 我应该如何将我的服务bean映射到dao bean或者应该只使用dao beans。 - 是否有任何需要使DAO类单身人士 - 如果我使用相同的dao bean的jsp，然后例如onSubmit如果我必须在多个表（dao beans）上输入数据，那我该怎么做。 1个服务bean要超过1个dao bean？

和设计使用的弹簧休眠良好的Web应用程序的任何refrence材料将赞赏;）

感谢

Answer 1

您必须使用服务豆。服务逻辑应该只在那里。 DAO只能用于DB相关操作。

现在你可以在你的服务bean中注入多个DAO。

Answer 2

DAO层和服务层是不同的实体：

DAO负责获取并把单个对象从\为DB。例如，从数据库中获取User（id，name，lastname）。

服务层负责您的业务逻辑。它可以使用几个DAO对象来执行一个动作。例如，将消息从一个用户发送到另一个用户，并将其保存在第一个用户的发送文件夹和收件人的收件箱中。

Answer 3

服务是关于向用户展示用户可以承担的业务功能的外观。基本上，如果您有一组低级用例，则该服务上的方法将与单个用户操作对齐。服务是事务性的，通常如果用户做了我们想要的事情的所有后果一起承诺。控制器和服务之间的分离意味着我们有一个地方可以放置webapp特定的功能，比如获取请求参数，进行验证，选择转发或重定向到的位置，以及放置业务逻辑的独立位置等取决于webapp apis，并且关于什么对象使用哪些数据访问对象更新哪些值并获得持久性。

我看到很多情况下，人们似乎认为他们需要每道道一项服务。我认为他们的假设是，因为数据访问对象和控制器和模型对于如何定义它们是相当机械的，所以服务必须是相同的方式，并且它们构建它们时不考虑正在实现的用例。会发生什么事情呢，除了有大量无用的服务样板代码之外，所有的业务逻辑都会在控制器混乱的情况下与Web特定的代码混淆在一起，并且控制器变得庞大而难以管理。如果你的应用程序非常简单，那么你可以在这里得到一段时间，但它是混乱的，很难测试，而且这通常是一个坏主意。分离关注点，将基础设施代码保存在一个地方，将业务代码保存在另一个地方，这是我们应该瞄准的目标，正确使用服务对实现目标非常有帮助。

Answer 4

FWIW - 我刚刚在Spring上通过类似的学习过程。好消息是，谷歌有很多例子，坏消息是，没有很多对于新手来说很好的“完整”例子（同样，如果你打算瞄准v3 Spring，那里会有很多v3以前的东西，这些东西可能会因为新的基线）。对我来说有效的是：从SpringSource站点上的示例应用程序开始（http://www.springsource.org/documentation）。在他们的一些例子之间，几乎所有的东西都是你需要的，至少是最简单的形式。当我在需要的示例中找到某些内容时，我会根据类似的术语（某些@注释等）进行搜索以找到有关该主题的更完整信息/更好的示例。许多搜索引导我回到这个网站，这就是为什么我开始在这里经常旅行 - 很多很好的问题已经得到解答。我想这不是一个非常有洞察力的答案，但是这个过程让我起床并在相当快的时间内完成基础知识。