当前位置: 首页 > 知识库问答 >
问题:

Spring:DTO和服务层

仲孙宇定
2023-03-14

我正在使用当前层拓扑:

1)道2)服务3)控制器(演示)

在我的一个控制器中,我收到以下呼叫(来自客户端):

public PlayerStatisticsDTO getPlayerStatistics(int playerId);

控制器现在应该将调用委托给服务层。

问题是,如果我创建一个如下方法:

public PlayerStatisticsDTO getPlayerStatistics(int playerId);

在我的服务中,我实际上让我的服务层意识到DTO对象!

我认为这是一种不好的做法(或者不是?)

因此,我提出的另一个选择是创建一个新类:

public class PlayerStatistics {...}

然后调用我的控制器:

 PlayerStatistics stats = this.service.getPlayerStatistics(playerID);
 return toDTO(stats);

这个解决方案的问题是我在我的项目中根本没有使用这个类,所以它看起来像是一个不必要的重复代码

共有1个答案

爱唯
2023-03-14

如果在请求的数据和正在呈现的数据之间有一对一的映射,在呈现层中使用DTO对象并不是一个糟糕的做法。如果您想在稍后阶段更改表示层,那么您可以创建一个包含表示属性的新POJO,并在服务层中映射它们。

 类似资料:
  • null null Tomcat服务器正在运行servlet,为mySQL数据库执行一些业务逻辑和hibernate框架。 现在我有点糊涂了。两台服务器都能接收HTTP请求吗?就像servlet从网页接收https请求和我的apache服务器一样? 并且两者都可以连接到数据库--使用php的apache服务器,正如我提到的,同时使用servlet的tomcat?

  • 我想知道每种方法的利弊是什么。例如,在graphQL中包含所有内容似乎有点多余,因为我们将在每个服务中复制模式的部分。另一方面,我们使用GraphQL来避免一些REST缺陷。我们担心拥有RESTendpoint会抵消从GQL获得的优势。 有人遇到过类似的困境吗?我们都没有使用GraphQL的经验,所以这里是否有一些明显的利弊我们可能会遗漏? 提前道谢!

  • 更准确地说,在我看来,BDD测试应该验证业务逻辑,而且只验证业务逻辑。在许多框架中,BDD测试场景是由滑板持有者用DSL创建的。BDD测试倾向于收敛于排他性的“不了解基础设施”的实践。另一方面,集成测试应该验证解决方案是否与目标基础结构匹配(它们由DevOps完成?),并且只与基础结构匹配。当业务功能通过微服务“分布”时,您应该模拟BDD测试环境(应该是本地环境)中的几乎所有内容(infra和bu

  • 让我们讨论一下微服务环境的体系结构。我们正在公司内部进行讨论,我想得到一些反馈。我认真考虑的是编排层(代码复制、更多移动部件改变api)。 网络应用- 原料药- 在这种情况下,服务不允许相互对话。业务流程层中的聚合服务 网络应用- 原料药- 这里允许服务相互对话,这里存在聚合服务。 账单属于哪里

  • 问题内容: 我们有几个微服务项目,每个项目都是独立的(在单独的spring boot服务器上运行,公开其余服务,使用单独的DB模式…) 我们使用Maven管理依赖关系。 有一个父pom将每个微服务声明为模块是一个好主意吗?因此,有助于管理公共依赖项(例如,在每个项目中都使用lib servlet-api witch,将其全部删除并仅在父pom中声明) 问题答案: 多模块父pom的“问题”是,没有复

  • 问题内容: 编辑2016年1月: 由于这仍然引起注意。自问了这个之后,我已经完成了一些AngularJS项目,对于我最常使用的那些项目,建立了一个对象并最后返回了该对象。但是,我下面的说法仍然正确。 编辑: 我想我终于了解了两者之间的主要区别,并且我有一个代码示例来演示。我也认为这个问题与建议的重复问题有所不同。重复项说明该服务不可实例化,但是如果您按照我在下面的演示中进行设置,它实际上是可实例化