所有功劳都归里克-安德森所有

生产应用程序通常限制使用模型子集输入和返回的数据。这背后有很多原因，安全是一个主要原因。模型的子集通常被称为数据传输对象(DTO)、输入模型或视图模型。

DTO可用于:

防止over-posting。 隐藏客户端不应该查看的属性。 为了减少有效负载大小，省略一些属性。 扁平化包含嵌套对象的对象图。 扁平化的对象图对客户来说更方便。

DTO方法的实际实现，由rick - anderson在微软Web api最佳教程和实践中使用c#和asp.net Core 5:

在MVC中，数据传输对象通常用于将域模型映射到最终由视图显示的更简单的对象。

从维基百科:

数据传输对象(DTO)，以前称为值对象或VO 一种用于在软件应用程序之间传输数据的设计模式 子系统。dto通常与数据访问一起使用 对象从数据库检索数据。

DefN

DTO是硬编码的数据模型。它只解决了由硬编码的生产过程处理的数据记录建模问题，其中所有字段在编译时都是已知的，因此可以通过强类型属性访问。

相反，动态模型或“属性包”解决了在运行时创建生产流程时对数据记录建模的问题。

瓦尔

DTO可以用字段或属性建模，但有人发明了一种非常有用的数据容器，称为Cvar。它是一个值的引用。当使用引用属性对DTO建模时，可以将模块配置为共享堆内存，从而在堆内存上协同工作。这完全消除了代码中的参数传递和O2O通信。换句话说，具有引用属性的dto允许代码实现零耦合。

    class Cvar { ... }

    class Cvar<T> : Cvar
    {
        public T Value { get; set; }
    }

    class MyDTO
    {
        public Cvar<int> X { get; set; }
        public Cvar<int> Y { get; set; }
        public Cvar<string> mutableString { get; set; } // >;)
    }

来源:http://www.powersemantics.com/

动态dto是动态软件的必要组件。要实例化动态流程，编译器的一个步骤是将脚本中的每台机器绑定到脚本定义的引用属性。动态DTO是通过将cvar添加到集合来构建的。

    // a dynamic DTO
    class CvarRegistry : Dictionary<string, Cvar> { }

论点

注意:由于Wix将使用dto组织参数标记为“反模式”，因此我将给出权威的意见。

    return View(model);  // MVC disagrees

我的协作架构取代了设计模式。参考我的网络文章。

Parameters provide immediate control of a stack frame machine. If you use continuous control and therefore do not need immediate control, your modules do not need parameters. My architecture has none. In-process configuration of machines (methods) adds complexity but also value (performance) when the parameters are value types. However, reference type parameters make the consumer cause cache misses to get the values off the heap anyway -- therefore, just configure the consumer with reference properties. Fact from mechanical engineering: reliance on parameters is a kind of preoptimization, because processing (making components) itself is waste. Refer to my W article for more information. http://www.powersemantics.com/w.html.

如果Fowler和他的公司了解其他架构，他们可能会意识到dto在分布式架构之外的好处。程序员只知道分布式系统。集成协作系统(又名生产又名制造)是我自己的架构，因为我是第一个用这种方式写代码的人。

Some consider the DTO an anemic domain model, meaning it lacks functionality, but this assumes an object must own the data it interacts with. This conceptual model then forces you to deliver the data between objects, which is the model for distributed processing. However on a manufacturing line, each step can access the end product and change it without owning or controlling it. That's the difference between distributed and integrated processing. Manufacturing separates the product from operations and logistics.

There's nothing inherently wrong with modeling processing as a bunch of useless office workers who e-mail work to one another without keeping an e-mail trail, except for all the extra work and headache it creates in handling logistics and return problems. A properly modeled distributed process attaches a document (active routing) to the product describing what operations it came from and will go to. The active routing is a copy of the process source routing, which is written before the process begins. In the event of a defect or other emergency change, the active routing is modified to include the operation steps it will be sent to. This then accounts for all the labor which went into production.

一些程序员使用DTO来区分将通过API传递的最终对象数据。它基本上是端点的有效载荷对象。比如，你可以将你传递给服务器的联系人表单值对象命名为contactFormDto或contactFromPayload，然后你或任何其他程序员都知道你在那个对象中拥有的是数据的最终形状，它将通过网络传播。

DTO是一个愚蠢的对象——它只保存属性，有getter和setter，但没有任何其他重要的逻辑(除了一个compare()或equals()实现)。

通常MVC中的模型类(假设这里是。net MVC)是dto，或者dto的集合/聚合

DTO的定义可以在Martin Fowler的网站上找到。dto用于将参数传递给方法并作为返回类型。很多人在UI中使用它们，但其他人从它们扩展域对象。