随着对现代技术适应缓慢的组织最终抛弃ejb，并准备向SpringBoot、微服务、REST、Angular转变，应用程序设计存在一些问题。一个是关于TransferObjects和Business Objects
- 当调用到REST控制器时，是否仍然流行填充to (POJO)然后进行Service调用，然后填充BusinessObject然后调用Repository服务?
或
- 在REST控制器层，我们直接填充BO并将其发送给服务(这对我来说没有任何意义，因为BO只在执行业务逻辑期间填充)。
如果现在它仍然是选项1，那么我们如何避免在大多数情况下编写完全相似的POJO类(为了使用BeanUtils.copyProperties())， BO用@Id， @Column等装饰。
详细说明@Turing85的评论…
选项1通常更有意义(见我回答的末尾)。这是一个责任(目的)和改变的问题;您引用的两个逻辑组件，一个REST API和一个存储库/系统服务:
责任- REST服务关心的是与它的调用者一起工作，所以理想情况下，在设计REST API时，你应该涉及客户端(客户端作为调用者)，因为如果API不能为他们工作，它就不会是一个有效的API。另一方面，存储库有点以自我为中心，可能需要考虑API调用者感兴趣或不感兴趣的事情(反之亦然)。
- 如果你关注设计原则，比如SOLID，你就会知道系统的一部分应该只做一项工作——作为限制它需要改变的原因的一种方式(参见:SRP)。试图在面向外部的API和面向内部的存储库中同时使用一个对象是自找麻烦的，因为它试图做的事情太多了——它试图帮助解决更广泛的解决方案中两个非常不同的部分的问题，而这两个部分都有非常不同的变化驱动因素在起作用。Turning85关于持久化层的评论也是基于同样的想法。
"选项1通常更有意义"
当REST API是系统API时，REST API的对象将/可以与那些击中实际存储库的对象非常相似(甚至可以被重用)。-即存储库的专用farade/代理。在这种情况下，系统API很大程度上是由存储库驱动的，也就是说，主要的更改驱动程序只是存储库。
经过一番研究，我同意，保持简单会导致更简单的代码。我发现了一个很好的简单的方法来处理这些手工工作。
https://www.baeldung.com/entity-to-and-from-dto-for-a-java-spring-application