N层POCO/DTO窘境

当只有邪恶的数据集和微软应用程序块时,层之间的传输对象将是数据集/数据表或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.

我要问的问题是你是不是要将数据拉入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();

这里指出的是,即使您使用ORM,您仍然可以利用DTO进行类似查询的报告,并让它完成所有繁重工作.