java应该让MVC应用程序中的服务返回实体或实体列表吗

Question

我有一个带有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的服务调用，而不是用户或指定人员列表

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

Answer 1

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

• 保持服务层对数据访问实现的清洁（例如：在服务层内部使用import java.sql.whatever是个坏主意）
• 服务层是放置声明性事务管理的理想场所。其想法是编写事务性服务层方法，在这一层下，有一个完全幼稚的DAO层，将注入它们的连接，在外部管理它们的错误，没有提交，没有回滚

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

Answer 2

好问题，但很难回答

我会尽力帮你找到适合你的答案：

服务抽象了什么

控制器抽象了什么

一组可能的答案是：

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

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

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

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

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

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

Answer 3

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

也就是说，在Spring中，有更好的方法来处理某些任务。例如，您希望从服务返回的XML可以由消息转换器生成。您需要做的就是在请求中请求XML，并从带有@ResponseBody注释的处理程序返回对象或ResponseEntity <T>

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

Answer 4

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

Answer 5

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

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

controller > facade > service > dao

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

http://en.wikipedia.org/wiki/Facade_pattern