我们应该如何处理 DTO？

Question

我有 2 个表，Patient 和 Registration，关系是一对多的。

在注册模块中，当我想编辑注册时，我调用GetRegistrationByID(int id) 以通过其ID 获取数据，并选择PatientCode 和PatientName 并将其解析为DTO。

在另一个模块中，我重复使用了GetRegistrationByID(int id)，但我需要有关患者信息的更多信息，例如性别、出生地点和日期、地址、村庄、地区、省份和电话号码。

对于这种情况，我有 2 个选项，更改 RegistrationDTO 以包含更多患者的信息，但结果是在注册模块中，当我调用 GetRegistrationByID(int id) 时，RegistrationDTO 变得更大。因为我只需要PatientCode和PatientName，现在还有多余的信息是不需要的。

第二个选项是我创建另一个方法GetPatientInfoByRegistrationID(int id)，但结果是数据库往返两次。我认为它破坏了 DTO 原则

data transfer object (DTO1[2]) 是一个携带数据的对象 进程之间。使用它的动机是沟通 进程之间通常使用远程接口（例如 Web 服务），其中每次调用都是一项昂贵的操作。 [2]因为 每次通话的大部分费用都与往返有关 客户端和服务器之间的时间，一种减少数量的方法 调用次数是使用一个对象（DTO）来聚合数据 会被几个电话转移，但这是服务的 只需一个电话。[2]

我正在努力学习如何让代码变得更好，那么我应该选择哪一个？请添加解释为什么它更好

Answer 1

费用可能没有你想象的那么大。仔细检查此部分：

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

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

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

然后设计您的 DTO。不需要所有信息都在一个类中。 DTO 可以镜像持久化的实体及其关系。在您的情况下，您有一个 Patient 和 Registration 表，因此您可以有相应的 DTO 类，如 PatientDTO 和 RegistrationDTO，其中患者 DTO 可以有一个注册列表，而注册 DTO 是一个字段相关患者。像这样的组合可以更轻松地获取隔离数据（例如，如果您只需要患者数据，而不需要注册）和重用类。

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

最后，DTO 不一定需要遵循实体的结构或属性名称。它们首先是为客户设计的，所以要为此设计。 DTO 可以是隐藏客户端不需要知道的持久结构的抽象。但在实践中，保持实体和 DTO 相似（如果不相同）通常不会令人困惑。设计良好的实体无论如何都会有清晰的结构和可理解的属性。