Java MVC应用程序中的服务是否应返回实体或实体列表

我有一个带有Spring和Hibernate的MVC应用程序

我让每个控制器调用调用dao的服务层

controller > service > dao

服务是否应始终返回一个实体

我试图将逻辑从控制器移动到服务。目前，这是控制器中的逻辑

autenticate

retrieve user information (service call)

retrieve his appointments (other service call)

create a status response in xml

return appointemnts

如您所见，如果我移动服务中的所有逻辑，我将需要一个返回xml的服务调用，而不是用户或指定人员列表

---

这是正确的方法，还是我应该将逻辑保留在控制器中并从仅服务实体返回？

据我所知，我认为这对您来说无关紧要。你必须记住的是

• 保持您的服务层没有数据访问实现（例如：在您的服务层中，

  导入java.sql.which

  将是一个坏主意）
• 服务层是放置声明性事务管理的理想场所。其思想是编写事务性服务层方法，在这一层下，有一个完全幼稚的DAO层，将注入它们的连接，在外部管理它们的错误，没有提交，没有回滚

---

将逻辑移出控制器层的想法是完全正确的。您对XML的关注是合理的，但是，无论您的服务层返回什么，请始终记住格式是表示层的问题。您的服务层（理想情况下还有控制器）应该完全不知道将为用户呈现的格式。这是一种获得适当的服务层的方法，该服务层可以在您为应用程序设计的许多表示层之间重用。

这是一个好问题，但很难回答

我将尽力帮助您找到适合您的答案：

服务抽象了什么

控制器抽象了什么

一组可能的答案是：

控制器通过访问机制（xml、http等）进行抽象

服务对业务逻辑进行抽象（注意矛盾修饰法），例如：谁能看到什么约会

DAO对存储内容的事实进行了抽象。从DAO获取约会的方式相同，尽管一个可能来自LDAP系统，另一个可能来自关系数据库

如果这些恰好是您的答案，您应该将用户信息的检索、约会和用户身份验证的检索移动到服务中，并将xml保留在控制器中

但是，你和你的团队需要如何对应用程序进行细分

---

一个帮助我找到合理答案的实验是思考其他客户。如果其他应用程序需要此信息，该怎么办。他们将访问什么，API应该是什么样子？

我想说不，服务不应该总是返回实体（或实体列表）

很难说没有实际的代码，但有时以下方法效果更好：

controller > facade > service > dao

facade为控制器提供了创建约会并返回xml的方法。同时，服务保持更干净，比如说只返回用户实体

---

不，服务可以返回您想要的一切。它为你提供的东西没有限制。即使是DAO或存储库也不必返回实体perse。他们只需要从数据库中返回您想要的任何内容

这就是说，使用Spring有更好的方法来处理某些任务。例如，您希望从服务返回的XML可以由消息转换器生成。您需要做的就是在请求中请求XML，并从带有

@ResponseBody

注释的处理程序返回对象或

ResponseEntity

---

尽可能多地将逻辑移出控制器。做大量工作的控制器很难测试。顺便说一下，这也适用于服务。最好将所有内容拆分为易于管理的小部分，而不是将大量工作单元放在一个地方。

我不会从服务层返回xml。考虑代码重用。如果以后在其他服务中需要该服务怎么办。对您更有用的是xml中显示的用户列表或用户对象列表。如果以后需要向用户提供json，该怎么办？控制器应将数据转换为可呈现的格式。至少这是我的意见