c# - DTO 的组件也是实体还是 DTO？

Question

我对术语有疑问。根据 Fowler 的说法，DTO 是“在进程之间传输数据以减少方法调用次数的对象”。 (http://martinfowler.com/eaaCatalog/dataTransferObject.html)。据我了解，减少方法调用的唯一方法是将它们联合起来。所以DTO是复合对象，包含一些实体。

例如，我们有两个简单的实体 CoinInfo 和 ProductInfo:

public class CoinInfo
{
    public int CoinId { get; set; }
    public int Denomination { get; set; }
    public int Quantity { get; set; }
}


public class ProductInfo
{
    public int ProductId { get; set; }
    public ProductTypes ProductType { get; set; }
    public int Price { get; set; }
    public int Count { get; set; }
}

我们还有复杂的对象 SomeDto，结合了 CoinInfo 和 ProductInfo。

public class SomeComplex
{
    public List<CoinInfo> UserWallet { get; set; }
    public List<ProductInfo> Products { get; set;}
}

那么，ProductInfo 和 CoinInfo 也是“DTO”还是只是“实体”？

Answer 1

当您跨越类、组件或应用程序边界时，数据传输对象就会发挥作用。您使用 DTO 来减少类、组件或应用程序之间的耦合。

例如，在构建供客户端使用的服务时，您可能需要引入三个组件:

• 服务:包含业务逻辑和可能的一些服务托管样板(尽管您通常希望在其自己的项目中最后一点)。
• 客户端库:应用程序可以用来调用服务中的方法
• 数据传输对象:服务和客户端都引用这些对象。

现在，希望与该服务通信的客户端应用程序只需引用客户端库和 DTO 库。您的服务使用哪些其他类型来发挥其魔力对客户来说根本不感兴趣，应该保持隐藏状态。

现在，DTO 的意义在于您可以使用它们来为 API 建模。您决定从您的服务中公开什么，以及这些数据的外观。您可以选择组合，将较小的 DTO 聚合成一个较大的 DTO，如您所示。

您必须牢记的是不要通过 DTO 暴露服务内部结构。您使用的是“实体”一词，这让我觉得您正在尝试公开例如在 DTO 中聚合的 Entity Framework 模型。你不应该这样做。这样做你正在创建一个“漏洞抽象”，使得更改数据库(添加或删除列，替换你的 ORM，...)和更改服务返回的信息(添加或删除属性，. ..).除此之外，使用 Entity Framework 模型作为 DTO 会引入批量分配、延迟加载和循环引用等问题，所有这些都需要解决方法。

您可以使用属性来解决这些潜在问题，让您的 ORM 或服务序列化程序忽略那些无关的属性，但这些仍然是解决方法。如果你真的需要公开看起来很像你的数据模型的 DTO，那么引入映射(例如使用 AutoMapper):

• Service.Data:包含“实体”。
• 服务:将“实体”映射到 DTO 并返回/接受后者。
• 客户端库:仍然只看到并需要引用 DTO。

在这种情况下，您的服务的数据层和从您的服务返回的模型是分离的。

如果您关心的不是所有这些，而只是命名法:是的，您显示的所有三个类都是 DTO。