我认为DTO可以是POCO。DTO更多地是关于对象的使用，而POCO更多地是关于对象的风格(与体系结构概念分离)。

One example where a POCO is something different than DTO is when you're talking about POCO's inside your domain model/business logic model, which is a nice OO representation of your problem domain. You could use the POCO's throughout the whole application, but this could have some undesirable side effect such a knowledge leaks. DTO's are for instance used from the Service Layer which the UI communicates with, the DTO's are flat representation of the data, and are only used for providing the UI with data, and communicating changes back to the service layer. The service layer is in charge of mapping the DTO's both ways to the POCO domain objects.

Martin Fowler说这种方法是一条艰难的道路，只有在域层和用户界面之间存在严重不匹配的情况下才应该采用。

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

我认为DTO可以是POCO。DTO更多地是关于对象的使用，而POCO更多地是关于对象的风格(与体系结构概念分离)。

One example where a POCO is something different than DTO is when you're talking about POCO's inside your domain model/business logic model, which is a nice OO representation of your problem domain. You could use the POCO's throughout the whole application, but this could have some undesirable side effect such a knowledge leaks. DTO's are for instance used from the Service Layer which the UI communicates with, the DTO's are flat representation of the data, and are only used for providing the UI with data, and communicating changes back to the service layer. The service layer is in charge of mapping the DTO's both ways to the POCO domain objects.

Martin Fowler说这种方法是一条艰难的道路，只有在域层和用户界面之间存在严重不匹配的情况下才应该采用。

甚至不要称它们为dto。他们被称为模型....句号。模特从来没有行为。我不知道是谁想出了这个愚蠢的术语DTO，但它一定是一个。net的东西，这是我所能想到的。想想MVC中的视图模型，同样的东西，模型是用来在层与层之间传递状态的服务器端或线上传输，它们都是模型。属性与数据。这些是你传递的模型。模特，模特。就是这样。

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

我就这个主题写了一篇文章:DTO vs值对象vs POCO。

简而言之:

DTO !=值对象 Dto⊂poco 价值对象⊂POCO

POCO只是一个不依赖于外部框架的对象。这是显而易见的。

POCO是否有行为无关紧要。

DTO可以是POCO，也可以是域对象(通常行为丰富)。

通常dto更可能依赖于外部框架(例如。属性)用于序列化的目的，因为它们通常在系统的边界处退出。

在典型的Onion风格架构中(通常在广泛的DDD方法中使用)，领域层被放置在中心，因此它的对象在这一点上不应该有该层之外的依赖关系。