当只有恶意数据集并且 microsoft 应用程序阻塞时，您在层之间的传输对象将是数据集/数据表或 DTO/POCO。我属于喜欢使用 DTO/POCO 的帮派。
现在随着 SubSonic、Entity Framework、NHibernate 等映射层的突然浪潮，我还应该使用我最喜欢的 POCO 吗？我主要这样做，当使用 ASP.net webforms 时，99% 的时间最终使用 ObjectDataSource 绑定到控件和特定于每种类型的功能。
我是否应该放弃对 POCO 的热爱并传递 IQueryables 或 Entities 或类似的东西并利用其他 DataSource 对象？
使用这些对象而不是 DTO 的优缺点是什么？它将如何影响我的应用程序设计和性能？
编辑：我什么时候可以使用其他数据源，如 Linq Datasorce 和 Entity 数据源等？
POCO 和 DTO 万岁。它们是轻量级的、易于序列化的、强类型的、可绑定的。他们从来没有任何性能问题，总是让我的更高级别的代码更干净。
使用 nHibernate 或其他可以映射到 POCO 的 ORM :-) 然后您可以根据您想要在生产者和消费者之间分离多少来决定传递 DTO 或 POCO。
我要问的问题是，您是否打算将数据拉入实体/IQueryables，然后将它们转换为 DTO？这是一个非常有效的模式，特别是如果您要转换服务边界并且不想公开您的域模型；但是有一个权衡。根据数据的大小，对性能的影响最小，但这是您需要测量的。
最近我不得不在下拉列表中显示一堆组织对象的列表。组织有很多属性和其他子对象。我的下拉菜单中不需要的只是一个 ID 和名称，以及一些额外的属性......
这是我的 HQL 查询，用于搜索数据库并使用 nHibernate 返回 DTO 列表：
return CurrentSession.CreateQuery(
"select new OrganizationListDTO(o.Id,o.Name,o.xxx,o.xxx)" +
" from Organization i where i.State=:state")
.SetParameter("state", state)
.List<IOrganizationListDTO>();
这里的要点是，即使您使用 ORM，您仍然可以利用 DTO 进行类似查询的报告，并让它完成所有繁重的工作。
我也在这个十字路口。对于 SOA，除了技术限制之外，还必须考虑其他一些原则——那就是如果你想保持在正确的轨道上。我已经看到一些人将这场辩论更进一步（包括我自己最初）并质疑如何交换业务对象（BO）。但我开始意识到这违反了 SOA 最基本的原则之一——自治。这样做会突然将您的服务绑定到业务细节。这只是我想提出来与 DataContract 和“实体”问题进行比较的一个场景。我认为这些原则更重要——即使是为了一点冗余（即专用 DTO）的成本。我更倾向于为此使用适配器模式，以保持消息传递“基础架构” 以及丰富的面向组件的模型，例如单独的 EDM。此外，使这种“适配器模式”成为一个全面的实体服务候选者，使其在 SOA 世界中更加优雅、可重用和自主。Thomas Erl 在他的著作《面向服务的架构（概念、技术和设计）》中出色地描述了“以实体为中心的服务”的概念。另一件需要思考的事情：如果我的“实体”不存在于单一来源中（即数据库的一部分和文本文件或电子表格的一部分）怎么办？通过接受 DTO 和/或成熟的以实体为中心的服务的额外努力，您可以将其隐藏起来并提高更高的敏捷性。Thomas Erl 在他的著作《面向服务的架构（概念、技术和设计）》中出色地描述了“以实体为中心的服务”的概念。另一件需要思考的事情：如果我的“实体”不存在于单一来源中（即数据库的一部分和文本文件或电子表格的一部分）怎么办？通过接受 DTO 和/或成熟的以实体为中心的服务的额外努力，您可以将其隐藏起来并提高更高的敏捷性。Thomas Erl 在他的著作《面向服务的架构（概念、技术和设计）》中出色地描述了“以实体为中心的服务”的概念。另一件需要思考的事情：如果我的“实体”不存在于单一来源中（即数据库的一部分和文本文件或电子表格的一部分）怎么办？通过接受 DTO 和/或成熟的以实体为中心的服务的额外努力，您可以将其隐藏起来并提高更高的敏捷性。一部分在数据库中，一部分在文本文件或电子表格中）？通过接受 DTO 和/或成熟的以实体为中心的服务的额外努力，您可以将其隐藏起来并提高更高的敏捷性。一部分在数据库中，一部分在文本文件或电子表格中）？通过接受 DTO 和/或成熟的以实体为中心的服务的额外努力，您可以将其隐藏起来并提高更高的敏捷性。
底线：如果您不关心 SOA 原则并且正在开发更多“临时”，那么请选择。但是，如果您处于企业或 B2B 职位，并且根本无法冒 SOA 打算驯服的臭名昭著的“临时蠕变”的风险，那么您可能会以 SOA 实体为中心的服务作为一等公民并照此管理它们。考虑计算的发展方向（SOA、SaaS、PaaS 等），以及它们共享的范例和原则。
我发现域和 DTO 的并行对象树令人反感。即使我使用代码生成器，要维护的额外代码也不会给我带来太多好处。我认为层纯度是超卖的。我不是 DTO 的粉丝。