列出差异：DTO、VO、实体、域、模型
List differences: DTO, VO, Entity, Domain, Model
现在我研究Spring使用JAVA平台启动。
我遇到的一个问题是如何区分 DTO、VO、实体、域和模型。
老实说，它们看起来太相似了，无法区分。
我已经检查了一些关于“DTO 和 VO 之间的区别”之类的 Whosebug 答案。
但是，我仍然想知道他们在 Spring Boot.
开发人员方面有何不同
总结
- 一个Entity:
是一个轻量级持久域对象。通常，一个实体表示关系数据库中的一个 table，每个实体实例对应于该 table 中的一行。实体的主要编程工件是实体 class，尽管实体可以使用帮助程序 classes.
DTO（数据传输对象）:
是用于在层与层之间传输数据的容器。
When you're working with a remote interface, each call is expensive and the number of calls should be reduced. The solution is to create a Data Transfer Object that can hold all the data for the call. It needs to be serializable to go across the connection. Usually an assembler is used on the server side to transfer data between the DTO and any domain objects. It's often little more than a bunch of fields and the getters and setters for them.
- VO - 一个值对象:
表示它自己是一组固定的数据，类似于Java enum。
A Value Object's identity is based on their state rather than on their object identity and is immutable. A real world example would be Color.RED, Color.BLUE, SEX.FEMALE etc.
领域模型:
包含所有实体和值对象。以及一些其他类型的 classes，具体取决于您使用的 classification。
模型:
定义模型属性的容器，主要用于向模型添加属性。
ModelMap:
是Model的扩展，能够在map和链式方法调用中存储属性。
ModelAndView:
是一个模型和一个视图的持有者；它允许 return 在一个 return 值中同时建模和查看。
Model, ModelMap, and ModelAndView are used to define a model in a Spring MVC application.
DAO（数据访问对象）或存储库:
数据访问对象抽象并封装了对数据源的所有访问。 DAO 管理与数据源的连接以获取和存储数据。
The DAO implements the access mechanism required to work with the data source. The data source could be a persistent store like an RDBMS, or a business service accessed via REST or SOAP.
The DAO abstracts the underlying data access implementation for the Service objects to enable transparent access to the data source. The Service also delegates data load and store operations to the DAO.
服务：
Service Layer 从接口客户端层的角度定义应用程序的边界及其可用操作集。
It encapsulates the application's business logic, controlling
transactions and coordinating responses in the implementation of its operations.
Though Putting business logic here is an anti-pattern introduced around the times of EJB 1.x and 2.x. Preferably, you should put the business-related functionality into Domain Model. Read about Anemic vs Rich Model: Anemic architecture - enemy of testing
图层
在了解 Spring 引导架构之前，您必须了解其中存在的不同层和 classes。 Spring Boot有四层如下：
表示层:
表示层处理 HTTP 请求，将 JSON 参数转换为对象，并验证请求并传递给业务层。简而言之，它由视图组成，即前端部分。
业务层:
业务层处理所有业务逻辑。它由服务 classes 组成，并使用数据访问层提供的服务。它还执行授权和验证。
持久层和数据库层:
持久层包含所有存储逻辑并将业务对象与数据库行进行转换。这也是执行 CRUD（创建、检索、更新、删除）操作的地方。
- 实体 - 是具有 ID 的 class。在关系数据库的情况下，它通常是 class 映射到具有一些主键的数据库 table。
- DTO（数据传输对象）- 是一个 class 可以很好地映射您通过网络发送的内容。例如。如果您交换 JSON 或 XML 数据，它的字段通常刚好足以填充那些 requests/responses。请注意，它可能比实体具有更少或更多的字段。
- VO（值对象）是一个 class-value。例如。您可以像 Grams 或 Money 那样创建 class - 它将包含一些原语（例如一些
double 值）并且可以使用这些原语比较值对象。他们没有数据库 ID。它们有助于用与我们的特定领域相关的更多 object-oriented class 替换原语。
- 域模型包含所有实体和值对象。以及一些其他类型的 classes，具体取决于您使用的 classification。
为了熟悉这些你应该阅读：
- Fowler 的企业应用程序模式。提到值对象和领域模型。
- Eric Evans 的领域驱动设计。提到实体、值对象和领域模型。
- 并可能熟悉 Java EE 设计模式。他们提到 DTO。但是这些文章写得很糟糕（如果它们仍然可以在互联网上找到的话）。令人困惑的是，他们也有定义与 DTO 非常相似的值对象，但没有人使用 VO 的定义。
这些只是文字，对于它们的确切含义没有普遍的共识。
它们在不同的项目中具有不同的含义，加入项目的一部分是学习这些 project-specific 定义。
此外，单词的定义 - 重叠，因为它们不是“一次性”发明的，而是传统上用于有影响力的书籍、博客等/
例如：
- DTO 是 2000 年代初期的概念；当时，官方 J2EE Java 强制使用（早已被遗忘和弃用的）“实体 EJB”与数据库交互。事实证明，使用它们的最佳模式是创建额外的“传输对象”，仅用于管理 DAO 和“会话 ejbs”（现在称为“服务”）之间的通信。然后 Hibernate 出现了，带来了“透明持久化”和“我们不需要单独的 DTO，我们可以只使用 POJO 实体”的想法。不久之后，J，
PA 诞生了。在一般人的印象中，“DTO”变成了“实体”，并且 DTO 这个名称被重新用于“为与外部系统接口而打包的任何类型的数据”。
- VO 通常用于“只读类型的 DTO”。但有时，在领域驱动设计中，人们用这个术语来对比领域对象：“实体”是可以改变并保持“不变”的对象，而“值对象”是不能改变的东西，因为它们会“变成别的东西”。例如，一辆汽车可以改变它的颜色，但它仍然是“同一辆车”。另一方面，日期“1977-04-05”不能“变异”为“2011-04-05”，因为它只会变成其他日期。
要点：
- 永远不需要知道单词的抽象定义。您将始终需要在上下文中理解它们；
- 不要相信（也不相信）那些试图告诉你关于这些定义的“绝对真理”的人。你总会发现同样聪明的人声称完全不同的东西。
- 理解软件架构没有坦途，没有“小结”。它更像是哲学或历史，而不是工程学。
现在我研究Spring使用JAVA平台启动。
我遇到的一个问题是如何区分 DTO、VO、实体、域和模型。
老实说，它们看起来太相似了，无法区分。
我已经检查了一些关于“DTO 和 VO 之间的区别”之类的 Whosebug 答案。
但是，我仍然想知道他们在 Spring Boot.
开发人员方面有何不同总结
- 一个Entity:
是一个轻量级持久域对象。通常，一个实体表示关系数据库中的一个 table，每个实体实例对应于该 table 中的一行。实体的主要编程工件是实体 class，尽管实体可以使用帮助程序 classes.
DTO（数据传输对象）:
是用于在层与层之间传输数据的容器。When you're working with a remote interface, each call is expensive and the number of calls should be reduced. The solution is to create a Data Transfer Object that can hold all the data for the call. It needs to be serializable to go across the connection. Usually an assembler is used on the server side to transfer data between the DTO and any domain objects. It's often little more than a bunch of fields and the getters and setters for them.
- VO - 一个值对象:
表示它自己是一组固定的数据，类似于Java enum。A Value Object's identity is based on their state rather than on their object identity and is immutable. A real world example would be Color.RED, Color.BLUE, SEX.FEMALE etc.
领域模型:
包含所有实体和值对象。以及一些其他类型的 classes，具体取决于您使用的 classification。模型:
定义模型属性的容器，主要用于向模型添加属性。ModelMap:
是Model的扩展，能够在map和链式方法调用中存储属性。ModelAndView:
是一个模型和一个视图的持有者；它允许 return 在一个 return 值中同时建模和查看。Model, ModelMap, and ModelAndView are used to define a model in a Spring MVC application.
DAO（数据访问对象）或存储库:
数据访问对象抽象并封装了对数据源的所有访问。 DAO 管理与数据源的连接以获取和存储数据。The DAO implements the access mechanism required to work with the data source. The data source could be a persistent store like an RDBMS, or a business service accessed via REST or SOAP.
The DAO abstracts the underlying data access implementation for the Service objects to enable transparent access to the data source. The Service also delegates data load and store operations to the DAO.
服务：
Service Layer从接口客户端层的角度定义应用程序的边界及其可用操作集。It encapsulates the application's business logic, controlling transactions and coordinating responses in the implementation of its operations.
Though Putting business logic here is an anti-pattern introduced around the times of EJB 1.x and 2.x. Preferably, you should put the business-related functionality into Domain Model. Read about Anemic vs Rich Model: Anemic architecture - enemy of testing
图层
在了解 Spring 引导架构之前，您必须了解其中存在的不同层和 classes。 Spring Boot有四层如下：
表示层:
表示层处理 HTTP 请求，将 JSON 参数转换为对象，并验证请求并传递给业务层。简而言之，它由视图组成，即前端部分。业务层:
业务层处理所有业务逻辑。它由服务 classes 组成，并使用数据访问层提供的服务。它还执行授权和验证。持久层和数据库层:
持久层包含所有存储逻辑并将业务对象与数据库行进行转换。这也是执行 CRUD（创建、检索、更新、删除）操作的地方。
- 实体 - 是具有 ID 的 class。在关系数据库的情况下，它通常是 class 映射到具有一些主键的数据库 table。
- DTO（数据传输对象）- 是一个 class 可以很好地映射您通过网络发送的内容。例如。如果您交换 JSON 或 XML 数据，它的字段通常刚好足以填充那些 requests/responses。请注意，它可能比实体具有更少或更多的字段。
- VO（值对象）是一个 class-value。例如。您可以像 Grams 或 Money 那样创建 class - 它将包含一些原语（例如一些
double值）并且可以使用这些原语比较值对象。他们没有数据库 ID。它们有助于用与我们的特定领域相关的更多 object-oriented class 替换原语。 - 域模型包含所有实体和值对象。以及一些其他类型的 classes，具体取决于您使用的 classification。
为了熟悉这些你应该阅读：
- Fowler 的企业应用程序模式。提到值对象和领域模型。
- Eric Evans 的领域驱动设计。提到实体、值对象和领域模型。
- 并可能熟悉 Java EE 设计模式。他们提到 DTO。但是这些文章写得很糟糕（如果它们仍然可以在互联网上找到的话）。令人困惑的是，他们也有定义与 DTO 非常相似的值对象，但没有人使用 VO 的定义。
这些只是文字，对于它们的确切含义没有普遍的共识。
它们在不同的项目中具有不同的含义，加入项目的一部分是学习这些 project-specific 定义。
此外，单词的定义 - 重叠，因为它们不是“一次性”发明的，而是传统上用于有影响力的书籍、博客等/
例如：
- DTO 是 2000 年代初期的概念；当时，官方 J2EE Java 强制使用（早已被遗忘和弃用的）“实体 EJB”与数据库交互。事实证明，使用它们的最佳模式是创建额外的“传输对象”，仅用于管理 DAO 和“会话 ejbs”（现在称为“服务”）之间的通信。然后 Hibernate 出现了，带来了“透明持久化”和“我们不需要单独的 DTO，我们可以只使用 POJO 实体”的想法。不久之后，J， PA 诞生了。在一般人的印象中，“DTO”变成了“实体”，并且 DTO 这个名称被重新用于“为与外部系统接口而打包的任何类型的数据”。
- VO 通常用于“只读类型的 DTO”。但有时，在领域驱动设计中，人们用这个术语来对比领域对象：“实体”是可以改变并保持“不变”的对象，而“值对象”是不能改变的东西，因为它们会“变成别的东西”。例如，一辆汽车可以改变它的颜色，但它仍然是“同一辆车”。另一方面，日期“1977-04-05”不能“变异”为“2011-04-05”，因为它只会变成其他日期。
要点：
- 永远不需要知道单词的抽象定义。您将始终需要在上下文中理解它们；
- 不要相信（也不相信）那些试图告诉你关于这些定义的“绝对真理”的人。你总会发现同样聪明的人声称完全不同的东西。
- 理解软件架构没有坦途，没有“小结”。它更像是哲学或历史，而不是工程学。