2011-01-11 29 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!

相關問題