我最近开始阅读一本书，该书更详细地解释了数据库的操作，特别是它们之间的关系。问题是这本书有点老了，是2014年的。所以我提出以下问题，请您澄清一下:
书中我们使用了 Dao、Dto 和 Service 模式，但我们不能使用 JPA、Spring Boot Repository 或其他新技术来“取代”书中介绍的旧实现？
如果是这样，您能给我一个替代以下代码的方法吗？它是如何工作的？我可以改进什么，可以放弃什么，应该完成什么，应该学习什么!
将应用程序的实现分为 2 个团队:
UserInterface(实体的数据传输对象，内存数据库中的单例和作为模拟服务和 View 的 Controller )
开发团队(创建实体并使用 TDD 进行测试，为该实体、业务服务层和表示层创建 DAO
那么，我可以改变这种创建和操作应用程序和数据库的方式，如果可以，如何改变，为什么？我应该使用什么，我应该怎么做？
这是我正在阅读的书的git:https://github.com/Spring-Hibernate-Book/spring-hibernate-datamodeling-tdd-rest/tree/master/Spring-OODD/src
最佳答案
就分工而言，在 Controller 层上有一个单独的团队工作的概念似乎已经过时了。单页 UI 可能有自己的团队，但许多地方更喜欢由同一个人从前到后处理某个功能的所有工作，以减少团队之间出现沟通问题的机会。
您需要 DTO 的程度应由开发人员自行决定。过去的做法是定期将所有实体复制到 DTO 中，以避免 UI 中延迟加载等问题。如果您正在构建一个单页应用程序，并将 JSON 传递到 UI，那么这不是问题。单页应用程序架构可以更好地分离 UI 关注点，从而在大多数情况下减少 DTO 的必要性。
对于其余的概念，应该进行映射。 Spring JPA 存储库具有与数据访问对象相同的功能，它只是为您提供更多的实现。与 Hibernate 映射相关的最大变化是使用 JPA 注释。服务没有改变。
太长了
发生变化的事情:
- 单页面应用程序已经取代了 JSP 等服务器端方法
- 标准化 JPA 而不是 Hibernate
- 配置类，不再有应用程序上下文 XML
- 个人资料
- 关注微服务与整体服务
- 包含更多电池(默认为 h2，可部署 jar，约定优于配置)
没有改变的事情:
- Controller 调用服务调用数据访问的一般分层方案
- Hibernate 映射策略和一般 ORM 问题
- Spring 事务支持
- 使用 bean、DI、AOP 的通用 Spring 编程模型
关于java - 使用 Spring Boot 代替 DTO、Dao、Service 的设计模式？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/65157408/