Design patterns 我们应该如何处理DTO？

我有两个表，

Patient

和

Registration

，它们之间的关系是一对多的

在注册模块中，当我想要编辑注册时，我调用

GetRegistrationByID（int-id）

以按id获取数据，还选择

PatientCode

和

PatientName

并将其解析为DTO

在另一个模块中，我重用了

GetRegistrationByID（int-id）

，但我需要更多关于患者信息的信息，如性别、出生地点和日期、地址、村庄、地区、省份和电话号码

对于这种情况，我有两个选项，更改注册数据以包含更多患者信息，但结果是在注册模块中，当我调用

GetRegistrationByID（int-id）

时，注册数据变得更大。因为我只需要

PatientCode

和

PatientName

，现在还有一些不需要的额外信息

第二个选项是我创建另一个方法

GetPatientInfoByRegistrationID（int-id）

，但结果是有两次到数据库的往返。我认为这违反了DTO原则

（DTO[2]）是一个承载数据的对象 进程之间。使用它的动机是交流 进程之间通常通过远程接口（例如。 web服务），其中每个调用都是昂贵的操作。[2]因为 每次通话的大部分费用都与往返有关 客户机和服务器之间的时间，减少数量的一种方法 of调用是使用一个对象（DTO）来聚合 本应通过几次呼叫进行转接，但已完成 只需一次电话。[2]

---

我正在努力学习如何使代码更好，那么我应该选择哪一个呢？请加上解释为什么这样更好

费用可能没有你想象的那么大。仔细检查本节：

由于每个调用的大部分成本与客户端和服务器之间的往返时间有关，因此减少调用次数的一种方法是使用一个对象（DTO），该对象聚合了本应由多个调用传输的数据，但仅由一个调用提供服务

这说明DTO用于服务器和某个客户机之间的通信，这可能包括网络开销（我说可能是因为在某些情况下，它可能是同一台服务器，例如在生成返回浏览器客户机的HTML时用于填充服务器端数据的DTO）。这就是为什么您希望将所需的信息包含到单个DTO中，而不是对所有内容进行单独调用的原因。例如，如果某个客户需要注册和患者信息，您希望避免他们需要进行两次单独的呼叫，这就是为什么您返回捆绑在DTO中的数据。否则，您将有两次完整的往返行程。然而，这并不意味着您需要不惜一切代价避免多个数据库查询。DTO是在服务器端合成的，在服务器上进行两次数据库查询以创建DTO并不像需要两次完整的客户机/服务器往返那样引人注目

另一个需要考虑的问题是，通常甚至可能不需要多个数据库查询。对象关系映射框架（如Java持久性API）通常允许您映射实体之间的关系，并指定是延迟（仅在请求时）获取实体，还是急切地获取实体。ORM可以通过使用只需要一个查询的连接来优化急取。仅仅因为DTO中有来自多个实体的信息，并不意味着它必然需要多个数据库查询

然后用于DTO的设计。所有信息不需要在一个类中。DTO可以镜像持久化实体及其关系。在您的案例中，您有一个

患者

和

登记

表，因此您可以有相应的DTO类，如

患者登记到

和

登记到

，其中患者DTO可以有一个登记列表，登记到相关患者的字段。这样的组合可以更容易地获取独立数据（例如，如果您只需要患者数据，而不需要注册）和重用类

对于不同的数据集，不一定需要不同的DTO。仅仅因为一个调用只应包含患者姓名和代码，而另一个调用包含更多信息，并不意味着您需要为此单独的DTO类。只需定义一个可以保存所有信息（对应实体）的类，并只填写所需内容。毕竟，客户通常知道自己想从电话中得到什么。如果希望能够区分由于不在数据库中而丢失的数据和未映射的数据，则可以在每个字段中使用一些标记来指示是否应该设置这些数据。或者字段类型可以是一些包装器对象，在设置它时会被标记，因此您现在可以确定它是

null

还是其他一些有意或无意的默认值

最后，DTO不一定需要遵循实体的结构或属性名称。它们首先是为客户设计的，所以要为此进行设计。DTO可以是抽象，用来隐藏客户端不需要知道的持久结构。但在实践中，如果实体和DTO不完全相同，保持它们相似通常也不那么容易混淆。设计良好的实体将具有清晰的结构和可理解的属性。

我明白了，您是对的“DTO是在服务器端编写的”。我几乎误解了。非常感谢，这是非常清楚和非常启发我。