使用 Spring Boot 代替 DTO、Dao、Service 的设计模式？ [关闭]答案

【问题标题】：Design Pattern using Spring Boot instead of DTO, Dao, Service? [closed]使用 Spring Boot 代替 DTO、Dao、Service 的设计模式？ [关闭]
【发布时间】：2021-03-17 07:46:29
【问题描述】：

我最近开始阅读一本书，该书更详细地解释了数据库的操作，尤其是它们之间的关系。问题是这本书有点旧，从 2014 年开始。所以我提出以下问题，请您澄清一下：

书中我们使用了 Dao、Dto 和 Service 模式，但我们不能使用 JPA、Spring Boot Repository 或其他新技术来“替换”书中介绍的旧实现？

如果是这样，您能否给我一个替代以下代码的方法，它是如何工作的？请问我可以改进什么，我可以放弃什么，应该完成什么，我应该学习什么！

Book 将应用程序的实现分为 2 个团队：

UserInterface（实体的数据传输对象，内存数据库和控制器中的单例作为模拟服务和视图）
开发团队（创建实体并使用 TDD 进行测试，为该实体、业务服务层和表示层创建 DAO

那么，我可以改变这种创建和操作应用程序和数据库的方式，如果可以，如何以及为什么？我应该使用什么，我应该怎么做？

【问题讨论】：

标签： java database spring-boot hibernate design-patterns

【解决方案1】：

就分工而言，在控制器层上有一个单独的团队工作的概念似乎已经过时了。可能是单页 UI 有自己的团队，但许多地方更喜欢由同一个人从头到尾为功能完成所有工作，以减少团队之间出现沟通问题的机会。

您需要 DTO 的程度应由开发人员自行决定。过去常常将所有实体复制到 DTO 中以避免 UI 中的延迟加载等问题。如果您正在构建一个单页应用程序，其中您将 JSON 传递给 UI，这不是问题。单页应用程序架构可以更好地分离 UI 关注点，在大多数情况下减少 DTO 的必要性。

对于其余部分，概念应该映射。 Spring JPA 存储库与数据访问对象具有相同的功能，它只是为您提供了更多的实现。与 Hibernate 映射相关的最大变化是改用 JPA 注释。服务没有改变。

TLDR

改变的地方：

单页应用程序已取代 JSP 等服务器端方法
在 JPA 而非 Hibernate 上进行标准化
配置类，不再有应用程序上下文 XML
个人资料
关注微服务与单体应用
包括更多电池（默认为 h2，可部署的 jars，约定优于配置）

没有改变的东西：

控制器调用服务调用数据访问的一般分层方案
Hibernate 映射策略和一般 ORM 问题
Spring 事务支持
带有 bean、DI、AOP 的通用 Spring 编程模型

【讨论】：

所以这本书已经过时了，谢谢你澄清这一点。我认为它在实体之间呈现的关系仍在使用中，所以很高兴知道它是如何工作的，即使实现已经改变，不是吗？你能给我推荐一本书或者一些能介绍这本书的东西吗？我感到困惑的另一件事是使用注释：服务、存储库。我想我们会将它用作 Jpa Repository 的存储库，但现在，Service 是干什么用的？在相应的书中，我们使用带有注释的 Service，但是已经过时了，我们可以在这种方法中改变一些东西吗？
@MyProblems：关于服务应该做什么，您可以尝试阅读stackoverflow.com/q/3688664/217324 或stackoverflow.com/q/3885675/217324。 spring 组件注解的使用没有改变，配置变得更容易了。
感谢您的链接和回答。如果我们使用 Spring Boot Repository 注解，我们可以使用它而不是使用 DAO 类吗？如果是，可以这样做吗？我的意思是这样做会容易得多。我看到并理解了Service注解的使用，谢谢。你知道我可以在哪里找到项目或类似这本书的东西，我可以从中了解更多信息吗？
spring-boot 有很多教程。取决于你想要什么，这本书可能还不错，只要理解它可能会假设更多的是一种老式的构建单体应用的方法，而 Spring 正试图面向微服务。