列出差异：DTO、VO、实体、域、模型

Question

现在正在研究JAVA平台的Spring Boot。

我面临的一个问题是如何区分 DTO、VO、Entity、Domain 和 Model 之间的区别。

老实说，这一切看起来都太相似了，无法区分。

我已经检查了一些有关“DTO 和 VO 之间的差异”之类的 stackoverflow 答案。

然而，我仍然想知道他们在使用 Spring Boot 的开发人员方面有何不同。

Answer 1

• 实体 - 是一个具有 ID 的类。对于关系数据库，它通常是一个映射到具有某些主键的数据库表的类。
• DTO（数据传输对象）- 是一个可以很好地映射您通过网络发送的内容的类。例如，如果您交换 JSON 或 XML 数据，它通常具有足以填充这些请求/响应的字段。请注意，它可能比实体具有更少或更多的字段。
• VO（值对象）是一个类值。例如，您可以创建像 Grams 或 Money 这样的类 - 它将包含一些原语（例如一些double值），并且可以使用这些原语来比较值对象。他们没有数据库 ID。它们有助于用与我们特定领域相关的更多面向对象的类替换原语。
• 域模型包含所有实体和值对象。还有一些其他类型的类，具体取决于您使用的分类。

为了熟悉这些，您应该阅读：

• Fowler 的企业应用程序模式。提到值对象和域模型。
• Eric Evans 的领域驱动设计。提及实体、值对象和域模型。
• 也许还可以熟悉 Java EE 设计模式。他们提到了DTO。但这些文章写得相当糟糕（如果它们仍然可以在互联网上找到的话）。令人困惑的是，他们还有 Value Object，其定义与 DTO 非常相似，但没有人使用 VO 的定义。

Answer 2

概括

1. 实体：
   是一个轻量级的持久性域对象。通常，实体代表关系数据库中的一张表，每个实体实例对应于该表中的一行。实体的主要编程工件是实体类，尽管实体可以使用帮助器类。

2. DTO（数据传输对象）：
   是用于在层与层之间传输数据的容器。

   当您使用远程接口时，每次调用的成本都很高，因此应减少调用次数。解决方案是创建一个可以保存调用的所有数据的数据传输对象。它需要可序列化才能通过连接。通常在服务器端使用汇编程序在 DTO 和任何域对象之间传输数据。它通常只不过是一堆字段以及它们的 getter 和 setter。

3. VO - 值对象：
   代表一组固定的数据，类似于 a Java enum。

   值对象的标识基于其状态而不是其对象标识，并且是不可变的。现实世界的示例是 Color.RED、Color.BLUE、SEX.FEMALE 等。

4. 领域模型：
   包含所有实体和值对象。还有一些其他类型的类，具体取决于您使用的分类。

5. Model：
   定义模型属性的持有者，主要用于向模型添加属性。

6. ModelMap：
   是 Model 的扩展，能够在映射和链式方法调用中存储属性。

7. ModelAndView：
   是模型和视图的持有者；它允许在一个返回值中返回模型和视图。

   Model、ModelMap 和 ModelAndView 用于在 Spring MVC 应用程序中定义模型。

8. DAO（数据访问对象）或存储库：
   数据访问对象抽象并封装了对数据源的所有访问。DAO 管理与数据源的连接以获取和存储数据。

   DAO 实现了使用数据源所需的访问机制。数据源可以是持久存储（例如 RDBMS），也可以是通过 REST 或 SOAP 访问的业务服务。

   DAO 抽象了 Service 对象的底层数据访问实现，以实现对数据源的透明访问。该服务还将数据加载和存储操作委托给 DAO。

9. 服务： AService Layer从连接客户端层的角度定义了应用程序的边界及其可用操作集。

   它封装了应用程序的业务逻辑，在其操作的实现中控制事务并协调响应。

   尽管将业务逻辑放在这里是 EJB 1.x 和 2.x 时代引入的反模式。最好将业务相关的功能放入域模型中。了解贫血与丰富模型：贫血架构 - 测试的敌人

层数

在了解 Spring Boot 架构之前，您必须了解其中存在的不同层和类。Spring Boot分为四层，如下：

1. 表示层：
   表示层处理HTTP请求，将JSON参数转换为对象，并对请求进行身份验证并将其传输到业务层。简而言之，它由视图（即前端部分）组成。

2. 业务层：
   业务层处理所有业务逻辑。它由服务类组成并使用数据访问层提供的服务。它还执行授权和验证。

3. 持久层和数据库层：
   持久层包含所有存储逻辑并将业务对象与数据库行进行转换。这也是执行 CRUD（创建、检索、更新、删除）操作的地方。

Answer 3

这些只是文字，对于它们的确切含义还没有达成普遍共识。

它们在不同的项目中具有不同的含义，加入项目的一部分就是学习这些项目特定的定义。

此外，这些词的定义是重叠的，因为它们不是“一次性”发明的，而是传统上用于有影响力的书籍、博客等/

例如：

• DTO是2000年代初期的概念；当时，官方 J2EE Java 强制使用（早已被遗忘和弃用的）“实体 EJB”与数据库交互。事实证明，使用它们的最佳模式是创建额外的“传输对象”，仅用于管理 DAO 和“会话 ejb”（现在称为“服务”）之间的通信。然后 Hibernate 出现了，带来了“透明持久性”和“我们不需要单独的 DTO，我们可以只使用 POJO 实体”的想法。不久之后，J、PA出生了。在一般观念中，“DTO”变成了“实体”，并且 DTO 名称被重新用于“打包用于与外部系统连接的任何类型的数据”。
• VO 通常用于“只读类型的 DTO”。但有时，在领域驱动设计中，人们使用这个术语来对比领域对象：“实体”是可以改变并保持“相同”的对象，而“值对象”是不能改变的东西，因为它们会“变得”其他的东西”。例如，一辆车可以改变它的颜色，但它仍然是“同一辆车”。另一方面，日期“1977-04-05”不能“变异”为“2011-04-05”，因为它只会变成其他日期。

要点：

• 永远不需要知道单词的抽象定义。你总是需要在上下文中理解它们；
• 不要相信（也不要相信）那些试图告诉您有关这些定义的“绝对真理”的人。你总会发现同样聪明的人声称的东西完全不同。
• 理解软件架构没有坦途，也没有“简要总结”。它更像是哲学或历史，而不是工程学。