2011-01-11 26 views
2

我正在使用DTO(数据传输对象)在我的应用程序的不同层之间传输信息。什么是正确填写DTO的方法

当涉及到性能和填充这些对象的方式时,最佳实践是什么?我应该使用我的数据访问层中的不同方法填写所需的最低信息吗?

比方说,我有以下类别:

public class Order 
{ 
    public int OrderNo; 
    public Customer Customer; 
    public double Total; 
} 

public class Customer 
{ 
    public int CustId; 
    public string CustName; 
    public Country Country; 
} 

public class Country 
{ 
    public int CountryId; 
    public string CountryName; 
} 

,如果我需要生成包含OrderNo,的CustName和国家或地区名称,并在另一种情况下,可能从不同的表,在不同的订单信息的列表会发生什么(或DTO的)?最好使用只包含必需字段的扁平DTO或使用LINQ进行查询?

我希望我说得够清楚。

感谢您的帮助!

编辑:我想知道的是,如果我应填写所有嵌套对象,并不仅是一个对象的属性的一部分。

+0

你能否在你的问题中澄清术语“图层”的用法?通常,您使用DTO在进程和机器之间传输数据。一个图层通常被称为您的代码的逻辑结构。例如,在单台机器提供的Web应用程序中,让您的数据访问层返回丰富的业务对象而非DTO是完全可以的。请参阅[Wikipedia](http://en.wikipedia.org/wiki/Multilayered_architecture)以获取有关此主题的起点。 – Marijn

+0

@Marijn:我有一个简单的3层Web应用程序,包含一个演示文稿,一个业务逻辑和一个数据访问层,但我正在使用这个小应用程序来弄清楚如何在我们公司构建一个包含400多个表,并且在许多这些表上将会有很多不同的操作和查询。 – Jason

回答

2

在我看来,你只需要DTO的[见Fowler's definition]如果你想跨机器或流程传输信息。例如:当您想要在与服务器通信的胖客户端中使用您的(部分)业务逻辑时,或者当您将数据访问处理从业务处理中分离出来时。当您希望在同一台机器上的进程之间共享信息时,DTO也很有用。

在这些情况下,我会使用Linq或其他自定义代码从业务对象创建DTO。按照@Tim建议的AutoMapper也可能有用。

设计DTO的IMO是设计远程接口的一部分。您不需要任何不必要的信息,以节省处理时间和网络流量。这可能是“扁平化”的情况。另一方面,你不想让你的DTO变得更小,而牺牲更多的“健谈的界面”。

注:

从你的问题,我得到你想要使用DTO对

传递信息从数据 ACCES层为您的企业的印象对象 在业务层

在我看来,这是一个非问题的许多Web应用程序,其中数据访问和业务ess逻辑在相同的过程中在同一台机器上执行。您不需要DTO就可以从数据库中检索业务对象 - 而是直接将数据存入数据库。为此,您可以使用ORM工具或自定义数据访问代码。

在业务层和表示层之间共享信息不一定需要DTO。

+0

有趣的相关问题:[poco-vs-dto](http://stackoverflow.com/questions/725348/poco-vs-dto)| [什么是数据传输对象](http://stackoverflow.com/questions/1051182/what-is-data-transfer-object)有趣的是:一个答案建议使用DTO作为模型在MVC(我会打电话这是一个视图模型) – Marijn

+0

您可以举一个例子来说明如何“将实体直接保存到数据库和从数据库中直接保存”。谢谢。 – Jason

+0

在.net中,我将使用ORM工具[NHibernate](http://nhforge.org/)与[repositories](http://martinfowler.com/eaaCatalog/repository.html)创建一个数据访问层。在开始使用NHibernate时,[FluentNHibernate](http://fluentnhibernate.org/)很棒。 – Marijn

6

我认为这将取决于你的DTO的使用范围以及它们的复杂程度。对于如图所示的简单方法,在填充所有字段时不太可能产生显着的性能影响,并且可以使使用通用映射代码变得更加容易。对于复杂对象图中的大量数据集,这将成为更多问题。

如果性能确实是一个问题,并且您可以通过进行更改来衡量您将获得的改进,那么我只会担心将对象展平或废除DTO(假设它们有意义)。

关于填充DTO,我们在多层ASP.NET MVC应用程序中广泛使用了LINQ和AutoMapper。 AutoMapper在我们的业务对象与传递给视图的哑视图模型对象之间进行映射时非常有用。虽然我们没有世界上最大的数据库,但我们有一个非常复杂的模式,并且由于映射而没有真正遭受任何性能瓶颈。

我们已经看到性能问题的一个地方是过早评估的LINQ查询,它会将大量对象图拉回,而不仅仅是需要的东西。通过检查“选择新的”在合适的时间执行,我减少了一个查询,从数据库中将850 MB数据从数据库拉到1.3 MB!

相关问题