Question

当只有邪恶的数据集和微软应用程序块时，层之间的传输对象将是数据集/数据表或DTO / POCO。我属于喜欢使用DTO / POCO的团伙。

现在有了SubSonic，Entity Framework，NHibernate等映射层的突然波动，我还应该使用我最喜欢的POCO吗？我主要这样做，当使用ASP.net webforms 99％时，最终使用ObjectDataSource来绑定控件和特定于每种类型的功能。

我是否应该放弃对POCO的热爱并传递IQueryables或Entities或类似的东西并使用其他DataSource对象？

使用这些对象代替DTO的优点和缺点是什么？它将如何影响我的应用程序设计和性能？

编辑：我什么时候可以使用其他数据源，如Linq Datasorce和Entity数据源等？

Answer 1

POCO和DTO万岁。它们重量轻，易于序列化，强类型，可绑定。从来没有遇到任何性能问题，总是使我的更高级代码更清洁。

Answer 2

使用nHibernate或其他可以映射到POCO的ORM :-)然后，您可以根据生产者和消费者之间需要的分离来决定传递DTO或POCO。

我要问的问题是你是不是要将数据拉入Entities / IQueryables然后将它们转换为DTO？这是一个非常有效的模式，特别是如果您要转换服务边界并且不想公开您的域模型;但是有一个权衡。根据数据的大小，性能最小化，但这是您需要测量的。

最近，我必须在下拉列表中显示一组Organization对象的列表。组织有许多属性和其他子对象。我所需要的所有东西都不是我需要的是一个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进行类似查询的报告，并让它完成所有繁重工作。

Answer 3

我也在这个十字路口。使用SOA，除了技术限制之外，还有其他必须考虑的原则 - 那就是如果你想要保持正确的轨道。我已经看到一些人将这个辩论更进一步（包括我自己最初），并质疑如何交换业务对象（BO）。但我开始意识到这违反了最基本的SOA原则之一 - 自治。这样做突然将您的服务绑定到业务细节。这只是我想提出的与DataContract和“Entities”问题进行比较的场景。我认为原则更重要 - 即使是一点点冗余（即专用DTO）的成本。为此，我更倾向于使用适配器模式，以保持消息传递“基础结构”和丰富的面向组件的模型，如EDM单独。此外，使这种“适配器模式”成为全面的实体服务候选者使其在SOA世界中更加优雅，可重用和自治。 Thomas Erl在其面向服务的架构（概念，技术和设计）一书中描述了“以实体为中心的服务”这一概念。另一件需要思考的事情：如果我的“实体”不在单一来源（即数据库中的一部分以及文本文件或电子表格中的一部分），该怎么办？通过接受DTO和/或完全成熟的以实体为中心的服务的额外努力，您可以隐藏它并提高灵活性。

底线：如果您不关心SOA原则并且正在开发更多“ad hoc”，那么请选择。但是，如果您处于企业或B2B职位并且无法冒着SOA打算驯服的臭名昭着的“临时蠕变”的风险，那么您可能会将SOA实体中心服务作为一等公民进行管理，并对其进行管理。考虑计算的发展方向（SOA，SaaS，PaaS等），以及它们共享的范例和原则。

Answer 4

我发现域和DTO的并行对象树是令人反感的。即使我使用代码生成器，要维护的额外代码也不会给我太多。我认为层纯度超卖。我不是DTO粉丝。

N层POCO / DTO窘境

4 个答案: