The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
数据传输对象，据我所知，是ORM设计模式的基石，我简直”崇拜”它。但我们来说重点：DTO真是令人羞愧，发明它的人就是错的。他所做的事情毫无借口。
顺便提一下，他的名字据我所知是Martin Fowler。也许他并不是DTO的唯一发明者，但他使其合法化并推荐使用。恕我直言，他错了。
面向对象编程的关键思想是将数据隐藏在对象后面。这个思想有一个名字：封装。在面向对象编程中，数据不能可见。对象只能访问它们封装的数据，而不能访问其他对象封装的数据。对于这个原则没有争论的余地—这就是面向对象编程的全部意义。
然而，DTO完全违背了这个原则。
让我们看一个实际的例子。假设这是一个从某个RESTful API获取JSON文档并返回DTO的服务，然后我们可以将其存储在数据库中：
我猜这是loadBookById()方法内部会发生的事情：
我是对的吗？我敢打赌我是对的。这对我来说已经看起来很恶心了。无论如何，让我们继续。这很可能会发生在saveNewBook()方法中（我正在使用纯JDBC）。
这个Book是数据传输对象设计模式的一个典型例子。它只是在两段代码、两个过程之间传输数据。book对象相当愚笨。它只知道…什么都不做。它实际上并不是一个对象，而是一个被动和贫血的数据结构。
什么是正确的设计？有几种选择。例如，我认为这个看起来不错：
这就是在 bookById() 中发生的事情:
这是在 Book.save() 中发生的事情：
如果有更多的书籍参数在JSON中，而这些参数无法很好地作为参数传递给单个的createBook()方法，会发生什么情况呢？这种情况该怎么处理呢？
还有很多其他选择。但主要观点是数据永远不会逃离对象book。一旦对象被实例化，数据对其他人来说是不可见且无法访问的。我们只能要求对象保存自身或将自身打印到某个媒体中，但我们永远不会从中获取任何数据。
DTO的概念本身是错误的，因为它将面向对象的代码变成了过程式的代码。我们有处理数据的过程，而DTO只是数据的一个容器。不要这样思考，也不要这样做。
另外，DTO还有几个其他名称：业务对象、领域对象（不包括DDD）、实体对象、JavaBeans。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 04:46
