我一直在使用Java Web应用程序示例中的SpringMVC，Hibernate和某些数据库。
有几种不同的方法可以执行此操作，但是此Spring 3和hibernate集成教程（带有示例）具有模型类，视图（在jsp中）以及控制器的服务和dao类。
我的问题是，服务类和DAO类是否都做同样的事情？您为什么同时需要它们？
这是我实际使用的教程：http : //fruzenshtein.com/spring-mvc-security-mysql-hibernate/
我一直在使用Java Web应用程序示例中的SpringMVC，Hibernate和某些数据库。
有几种不同的方法可以执行此操作，但是此Spring 3和hibernate集成教程（带有示例）具有模型类，视图（在jsp中）以及控制器的服务和dao类。
我的问题是，服务类和DAO类是否都做同样的事情？您为什么同时需要它们？
这是我实际使用的教程：http : //fruzenshtein.com/spring-mvc-security-mysql-hibernate/
Answers:
通常，DAO尽可能轻巧，并且仅用于提供与DB的连接，有时是抽象的，因此可以使用不同的DB后端。
服务层在那里提供逻辑，以对发送到DAO和客户端的数据以及从DAO和客户端发送的数据进行操作。通常，这两部分会捆绑在一起，成为同一模块，有时也捆绑为同一代码，但是您仍然会看到它们是不同的逻辑实体。
另一个原因是安全性-如果您提供的服务层与数据库无关，那么除了通过服务之外，从客户端获得对数据库的访问会更加困难。如果无法直接从客户端访问数据库（并且没有琐碎的DAO模块充当服务），那么接管客户端的所有攻击者所能做的就是尝试在攻击者获取除服务器之外的所有内容之前入侵服务层。最方便的数据访问方式。
我是有关帖子的作者。我在不同技术和不同体系结构上的工作有相当一部分。基于以上所述，我可以肯定地说拥有服务层和dao层始终是一个好主意。DAO应该仅限于仅向数据库中添加/更新/插入/选择实体对象，仅此而已。如果要在逻辑方面做任何额外的事情，请将其添加到服务层。这将有助于使代码模块化，并在替换数据库（对于数据的某些部分）时易于替换。这特别适用于涉及报表的应用程序，这些报表即使从数据库中获取数据后也具有沉重的逻辑。
同样，在春季，安全性将理想地应用于服务层。您不想更改这种方式。
Adam Bien在他的书中指出，JPA EntityManager是DAO的良好通用实现这一事实：
在Java EE世界中，几乎不需要编写自己的DAO，因为JPA实现包括一个。您只需要编写服务层。
实施您自己的DAO层确实是15年前非常糟糕的J2EE架构的一个后遗症，但是许多人仍然感到必须这样做。这些自定义DAO层通常仅提供转发功能，这些功能在EntityManager上调用相应的方法。
因此，要回答您的问题，是的，您需要一个服务层和一个DAO，但是您只需要编写服务层即可。
我发现服务层在大多数情况下会增加不必要的复杂性。从理论上讲，是为了避免在dao层中包含业务逻辑，但是最终这会导致混乱，甚至有些人因为认为它并没有增加价值而拒绝完全删除dao层。http://ayende.com/blog/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer
但是，如果您有多种业务逻辑，那么可以。这是一个好主意。 建立服务层有多重要？
恕我直言，服务层可以视为控制器和DAO层之间的层。该服务层正是我们可以添加业务逻辑，甚至创建特定于视图需要呈现的返回对象的地方。