普通旧 CLR 对象与数据传输对象

Question

POCO = 普通旧式 CLR（或更好：类）对象

DTO = 数据传输对象

在此 post 是有区别的，但坦率地说，我读过的大多数博客都以 DTO 的定义方式描述 POCO：DTO 是简单的数据容器，用于在各层之间移动数据。一个应用程序。

POCO和DTO是同一个东西吗？

Answer 1

POCO 遵循 OOP 规则。 它应该（但不一定）具有状态和行为。 POCO 源自 POJO，由 Martin Fowler 创造[这里有轶事]。 他使用 POJO 一词来让拒绝框架重的 EJB 实现变得更加性感。 POCO 应该在 .Net 中的相同上下文中使用。 不要让框架决定对象的设计。

DTO 的唯一目的是传输状态，并且不应该有任何行为。 有关使用此模式的示例，请参阅 Martin Fowler 的DTO 说明。

区别如下：POCO 描述了一种编程方法（良好的老式面向对象编程），其中 DTO 是一种用于使用对象“传输数据”的模式。

虽然您可以像对待 DTO 一样对待 POCO，但如果出现以下情况，您就会面临创建贫乏域模型的风险：你这样做。 此外，结构上也存在不匹配，因为 DTO 应该被设计为传输数据，而不是代表业务域的真实结构。 这样做的结果是 DTO 往往比您的实际域更加扁平。

在任何合理复杂性的域中，创建单独的域 POCO 并将其转换为 DTO 几乎总是更好。 DDD（域驱动设计）定义了反腐败层（另一个链接此处，但最好的办法是 购买这本书），这是一个很好的结构，可以使隔离清晰。

Answer 2

对我来说，贡献可能是多余的，因为我已经在我的博客文章中阐述了我的立场，但该文章的最后一段总结了一些事情：

所以，总而言之，学会热爱 POCO，并确保你不喜欢 POCO。不要传播任何关于它与 DTO 相同的错误信息。 DTO 是简单的数据容器，用于在应用程序的各层之间移动数据。 POCO 是成熟的业务对象，唯一的要求是它们是持久性无知的（没有获取或保存方法）。 最后，如果您还没有读过吉米·尼尔森的书，请从当地大学书库中获取。 它有 C# 示例，读起来很棒。

顺便说一句，帕特里克，我将 POCO 作为一篇生活方式文章来阅读，我完全同意，这是一篇很棒的文章。 这实际上是我推荐的吉米·尼尔森（Jimmy Nilsson）书中的一个部分。 我不知道它可以在网上找到。 他的书确实是我发现的有关 POCO / DTO / Repository / 和其他 DDD 开发实践的最佳信息来源。

Answer 3

POCO 只是一个不依赖于外部框架的对象。 它很简单。

POCO 是否有行为并不重要。

DTO 可以是 POCO，也可以是域对象（通常具有丰富的行为）。

通常，DTO 更有可能出于序列化目的而依赖于外部框架（例如属性），因为它们通常存在于系统边界。

在典型的洋葱风格架构中（通常在广泛的 DDD 方法中使用），域层位于中心，因此此时其对象不应该具有该层之外的依赖项。

Answer 4

我为该主题写了一篇文章： DTO 与值对象与 POCO 相比。

简而言之：

• DTO != 值对象
• DTO ⊂ POCO
• 值对象 ⊂ POCO

Answer 5

TL;DR：

DTO 描述了状态传输的模式。 POCO 没有描述太多东西，只是没有什么特别之处。 这是 OOP 中“对象”的另一种表达方式。 它来自 POJO (Java)，由 Martin Fowler 创造，他实际上只是将其描述为“对象”的一个更奇特的名称，因为“对象”不是很性感，人们因此避免使用它。

扩展...

好吧，以我认为需要的更加高雅的方式解释这一点，从您关于 DTO 的原始问题开始：

DTO 是一种用于在关注层之间传输状态的对象模式。 它们可以有行为（即技术上可以是 poco），只要该行为不会改变状态。 例如，它可能有一个将自身序列化的方法。 要成为一个合适的 DTO，它需要是一个简单的属性包； 需要明确的是，该对象不是一个强模型，它没有隐含的语义含义，并且它不强制执行任何形式的业务规则或不变量。 它实际上只是为了移动数据而存在。

POCO 是一个普通对象，但“普通”的意思是它并不特殊，没有任何特定的要求或约定。 它只是意味着它是一个没有隐含模式的 CLR 对象。 通用术语。 我还听说它被扩展来描述这样一个事实：它也不能与其他框架一起使用。 因此，例如，如果您的 POCO 在其属性上有一堆 EF 装饰，那么我认为它不是一个简单的 POCO，它更多地属于 DAO 领域，我将其描述为以下内容的组合： DTO 和其他数据库问题（例如映射等）。 POCO 是免费且不受阻碍的，就像您在学校学习创建的对象一样。

这里有一些不同类型对象模式的示例可供比较：

• 视图模型：用于对视图的数据进行建模。 通常有数据注释来协助特定视图（即通常不是共享对象）的绑定和验证，或者在当今时代，特定视图组件（例如React）。 在MVVM中，它还充当控制器的角色。 它不仅仅是一个 DTO； 它不是传输状态，而是呈现状态，或者更具体地说，以对 UI 有用的方式形成该状态。
• 值对象：用于表示值，应该是不可变的
• 聚合根：用于管理状态和不变量。 不应允许引用除 ID
• 处理程序之外的内部实体：用于响应事件/消息。
• 属性：用作装饰来处理横切关注点。 可能只允许在某些对象级别上使用（例如，属性但不是类、方法但不是属性等）
• 服务：用于执行复杂的任务。 通常是某种形式的立面。
• 控制器：用于控制请求和响应的流程。 通常仅限于特定协议或充当某种中介； 它负有特殊的责任。
• 工厂：用于配置和/或组装复杂对象，以便在构造函数不够好时使用。 还用于决定需要在运行时创建哪些对象。
• Repository/DAO：用于访问数据。 通常公开 CRUD 操作或者是表示数据库模式的对象； 可以用特定于实现的属性来标记。 事实上，这些模式 DAO 对象之一实际上是另一种 DTO...
• API 契约：可能用序列化属性进行标记。 通常需要有公共 getter 和 setter，并且应该是轻量级的（不是过于复杂的图）； 与序列化无关的方法不典型且不鼓励。

这些可以被视为只是对象，但请注意，它们中的大多数通常与模式相关或具有隐含的限制。 因此，您可以将它们称为“对象”，或者您可以更具体地说明其意图并按其本质来称呼它。 这也是我们有设计模式的原因； 用几句话描述复杂的概念。 DTO 是一种模式。 聚合根是一种模式，视图模型是一种模式（例如MVC和MVVM）。

POCO 不描述模式。 它只是 OOP 中引用类/对象的一种不同方式，可以是任何东西。 将其视为一个抽象概念； 他们可以指任何事物。 在我看来，这是一种单向关系，因为一旦一个对象达到只能完全服务一个目的的地步，它就不再是 POCO。 例如，一旦您用装饰标记您的类以使其与某些框架一起工作（即“检测”它），它就不再是 POCO。 因此，我认为存在一些逻辑关系，例如：

• 是 POCO（直到它被检测）
• POCO 可能不是 DTO
• 视图模型是 POCO（直到它被检测）
• POCO 可能不是视图模型

DTO 区分两者是为了保持模式清晰和一致，以避免交叉关注并导致紧密耦合。 例如，如果您有一个业务对象，它具有改变状态的方法，但也使用 EF 装饰来保存到 SQL Server 和 JsonProperty，以便可以通过 API 端点发送回。 该对象无法容忍更改，并且可能会散布各种属性的变体（例如 UserId、UserPk、UserKey、UserGuid，其中一些标记为不保存到数据库，另一些标记为不序列化到API 端点处的 JSON）。

因此，如果您告诉我某个东西是 DTO，那么我可能会确保它除了移动状态之外从未用于任何其他用途。 如果你告诉我某个东西是视图模型，那么我可能会确保它没有保存到数据库中，并且我知道可以将“hacky”东西放在那里以确保数据可用通过用户界面。 如果你告诉我某个东西是领域模型，那么我可能会确保它不依赖于域之外的任何内容，当然也不依赖于任何技术实现细节（数据库、服务等），仅依赖于抽象。 但是，如果你告诉我某个东西是 POCO，那么除了它不是也不应该被检测之外，你根本就不会告诉我太多。

示例

这是一个弱但准确的示例，应该很容易理解。

这可能是 POCO，也可能是 DTO。 它只是一个对象； 没什么特别的。 看起来像一个弱类型的属性包，但没有什么值得注意的地方。

public class CreateUserRequest
{
    public string Name { get; set; }

    public string Email { get; set; }
}

这不再是 POCO

public class CreateUserRequest
{
    [JsonPropertyName(Name = "name")]
    public string Name { get; set; }

    [JsonPropertyName(Name = "email")]
    public string Email { get; set; }
}

为什么不再是 POCO？ 因为它显然是一个数据协定，旨在与 System.Text.Json 序列化程序一起使用。 它现在更接近 DTO，但针对特定框架进行了检测。

下一个是当您不进行这些区分时会发生的情况

[Table("Users")]
public class CreateUserRequest
{
    [Key]
    [JsonIgnore]
    public string Id { get; set; }

    [JsonPropertyName(Name = "name")]
    public string Name { get; set; }

    [JsonPropertyName(Name = "email")]
    public string Email { get; set; }

    public int LoginCount { get; set; }

    public void IncrementLogin() => LoginCount++;
}

所以现在这绝对不再是 POCO 了。 它看起来像是某种 DTO，但它的用途是超载的。 是 API 合约还是 DAO？ 它似乎既可以作为 JSON 合约，又可以与数据库 ORM 一起使用。 需要额外的工具来防止它从 REST API 中泄漏数据库 PK。 它还具有一种改变状态的方法，就好像有人将其用作域实体一样。 甚至不清楚开发人员是否希望将 LoginCount 作为 JSON 合约或数据库架构的一部分。

我从开发人员那里看到很多这样的类，他们认为通过重用类可以节省时间。 他们认为这是干的。 我想你可能会说它是 DRY，但实际上，它是人为的、紧密耦合的，可能违反了其他 5 个设计理念，并且最终会在未来把你搞砸。

历史

福勒解释的 ：在一个对象很奇特的世界中（例如遵循特定的模式，有仪器等），它在某种程度上鼓励人们避免使用不奇特的对象来捕获业务逻辑。 所以他们给它起了一个好听的名字POJO。 如果你想要一个例子，他指的是“Entity Bean”，它是具有非常具体的约定和要求等的对象之一。如果你不知道那是什么 -->; Java Bean。

相比之下，POJO/POCO 只是您在学校学习如何创建的常规 ole 对象。

Answer 6

我认为 DTO 可以是 POCO。 DTO 更多的是关于对象的使用，而 POCO 更多的是对象的风格（与架构概念解耦）。

POCO 与 DTO 不同的一个例子是当您在域模型/业务逻辑模型中谈论 POCO 时，这是问题域的一种很好的 OO 表示。 您可以在整个应用程序中使用 POCO，但这可能会产生一些不良的副作用，例如知识泄漏。 例如，DTO 从与 UI 通信的服务层使用，DTO 是数据的平面表示，并且仅用于向 UI 提供数据，并将更改传达回服务层。 服务层负责将DTO的双向映射到POCO域对象。

更新 Martin Fowler 说这种方法是一条艰难的道路仅当域层和用户界面之间存在显着不匹配时才应采取。

Answer 7

DTO 的主要用例是从 Web 服务返回数据。 在这种情况下，POCO 和 DTO 是等效的。 POCO 中的任何行为在从 Web 服务返回时都会被删除，因此它是否具有行为并不重要。

Answer 8

DTO 对象用于将数据反序列化为来自不同源的对象。 这些对象不是您的模型 (POCO) 对象。 您需要将这些对象转换为模型 (POCO) 对象。 转换主要是复制操作。 如果是内部源，则可以直接从源填充这些 POCO 对象，但如果是外部源，则不建议这样做。 外部源具有 API 以及它们所使用的架构的描述。 在 DTO 中加载请求数据，然后在 POCO 中转换这些数据要容易得多。 是的，这是一个额外的步骤，但有原因。 规则是将源中的数据加载到对象中。 它可以是 JSON、XML 等。 加载后，然后将该数据转换为模型中所需的数据。 所以大多数时候 DTO 是外部源的对象图像。 有时您甚至可以获得源提供者的架构，然后您可以更轻松地反序列化，XML 的工作方式与 XSD 类似。

Answer 9

这是一般规则：DTO==邪恶，是过度设计软件的指标。 POCO==好。 “企业”模式已经摧毁了 Java EE 世界中很多人的大脑。 请不要在.NET 领域重蹈覆辙。

Answer 10

甚至不要称它们为 DTO。 他们被称为模型......时期。 模型从来没有行为。 我不知道是谁想出了 DTO 这个愚蠢的术语，但我只能想到它一定是 .NET 的东西。 想想 MVC 中的视图模型，同样的东西，模型用于在服务器端层之间或通过线路传输状态，它们都是模型。 带有数据的属性。 这些是您通过网络传递的模型。 模型，模型模型。 就是这样。

我希望 DTO 这个愚蠢的术语能够从我们的词汇中消失。