The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
有人问我对DAO的看法，我意识到，尽管我写过ORM、DTO和getters，但我还没有机会提及DAO。以下是我的看法：它和它的朋友ORM、DTO和getters一样令人遗憾。简而言之，数据访问对象是一个对象，它”提供对某种类型的数据库或其他持久化机制的抽象接口“。它的目的是崇高的，但实现却很糟糕。
以下是它的可能样子：
这个想法很简单—方法find()创建了一个DTO Book，然后其他人向其注入新的数据并调用update()。
你问什么有问题？和ORM一样的问题，但是不再有“session”，我们有了DAO。问题依旧：book不是一个对象，而是一个数据容器。我引用了我在ORM文章中的三年前的声明，稍微改了一下名字：“DAO不是将数据库交互封装在一个对象中，而是将其提取出来，实质上撕裂了一个坚固而有凝聚力的有机体。”有关详细信息，请查看该文章。
然而，我不得不说，我在我大多数个人项目中都有类似的DAO，但它们不返回或接受DTO。相反，它们返回对象，并有时接受对它们的操作。以下是一些示例。看看Wring.io中的Pipes接口：
它的add()方法在”collection”中创建一个新项目，而pipe()方法从集合中返回一个单一对象。Pipe 不是一个数据传输对象（DTO），它是一个完全能够执行所有必要数据库操作的普通对象，不需要DAO的任何帮助。例如，它有一个Pipe.status(String)方法来更新其状态。我不打算使用Pipes，我只需要执行 pipe.status("Hello, world!")。
这里还有一个来自Jare.io的例子：接口Base，它返回一个类型为Domain的对象列表。然后，当我们想要删除一个域名时，我们只需调用domain.delete()。该域名完全能够执行所有必要的数据库操作。
我相信DAO的问题就在于它的名称。它表明我们正在访问”数据”并且确实如此：它去数据库中检索一些数据并返回数据。不是对象，而是数据，也就是所谓的”数据传输对象”。正如我们之前讨论的那样，直接的数据操作会破坏封装性并使面向对象的代码过程化和难以维护。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 10:36
