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

本文介绍了普通的旧CLR对象与数据传输对象的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

POCO =普通的旧CLR(或更高级:类)对象

POCO = Plain Old CLR (or better: Class) Object

DTO =数据传输对象

DTO = Data Transfer Object

在此帖子有所不同，但坦率地说，我读过的大多数博客都以定义DTO的方式描述了POCO:DTO是用于在应用程序各层之间移动数据的简单数据容器.

In this post there is a difference, but frankly most of the blogs I read describe POCO in the way DTO is defined: DTOs are simple data containers used for moving data between the layers of an application.

POCO和DTO是同一个人吗?

Are POCO and DTO the same thing?

推荐答案

POCO遵循OOP规则.它应该(但不是必须)具有状态和行为. POCO来自POJO，由Martin Fowler创造[此处注释].他使用术语POJO来使拒绝框架繁重的EJB实现更加性感. POCO应该在.Net中的相同上下文中使用.不要让框架来决定对象的设计.

A POCO follows the rules of OOP. It should (but doesn't have to) have state and behavior. POCO comes from POJO, coined by Martin Fowler [anecdote here]. He used the term POJO as a way to make it more sexy to reject the framework heavy EJB implementations. POCO should be used in the same context in .Net. Don't let frameworks dictate your object's design.

DTO的唯一目的是转移状态，并且不应有任何行为.有关使用此模式的示例，请参见Martin Fowler的 DTO的解释.

A DTO's only purpose is to transfer state, and should have no behavior. See Martin Fowler's explanation of a DTO for an example of the use of this pattern.

区别在于: POCO描述了一种编程方法(一种很好的老式面向对象编程)，其中 DTO是一种模式，用于通过以下方式传输数据"对象.

Here's the difference: POCO describes an approach to programming (good old fashioned object oriented programming), where DTO is a pattern that is used to "transfer data" using objects.

虽然您可以将POCO像DTO一样对待，但是冒着创建贫血域模型的风险如果您这样做.此外，由于DTO应该被设计为传输数据，而不是代表业务域的真实结构，因此结构上存在不匹配.这样的结果是DTO往往比您的实际域平坦.

While you can treat POCOs like DTOs, you run the risk of creating an anemic domain model if you do so. Additionally, there's a mismatch in structure, since DTOs should be designed to transfer data, not to represent the true structure of the business domain. The result of this is that DTOs tend to be more flat than your actual domain.

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

In a domain of any reasonable complexity, you're almost always better off creating separate domain POCOs and translating them to DTOs. DDD (domain driven design) defines the anti-corruption layer (another link here, but best thing to do is buy the book), which is a good structure that makes the segregation clear.