如何處理和組織不同環境下的DTO？

Question

在各種場景中使用簡單的DTO時，我經常遇到同樣的問題，我總是想知道是否有更好的方法來處理它。

事情是，我有一個業務對象，例如， Asset它有一堆屬性，子對象和計算字段，其中一些在時間意義上計算很昂貴，其中一些在數據amonut意義上是巨大的。我需要在UI的各種屏幕中使用不同的對象風格，例如

在一棵樹上那裏是顯示一個層次，我也不需要比顯示名稱在網格
• 在那裏我展示在詳細信息窗格只是一對夫婦的屬性
• 更
• 那裏的可用信息的大子集，但還是它的一些（如映射對象）是隻能顯示在需求

爲了能夠使用此方案來實現最佳的性能，我一直都創建了不同的DTO爲每個上下文，只包含實際使用的信息的子集在這方面。雖然是一個資源優化的解決方案，這將導致兩個問題：

• 我有一個類爆炸與DTO類的數量龐大
• 我想出了同樣的事情，不同的名字很辛苦像AssetDtoForGridInTheOverviewScreenInTheUpperPaneAboveTheSplitter，何況以後保持他們
• 我經常重複自己的轉化方法，因爲有被最的的DTO中使用，但不是所有的他們（的所以我不能屬性把它們放入任何超類並重用轉換邏輯）

我正在使用的技術是ASP.NET SOAP WebServices和C＃3.5，但我認爲這可能是一個語言不可知的問題。歡迎任何想法..

Answer 1

這是DTO的已知問題。這在其他平庸的articule on MSDN中有描述。解釋：DTO是最通用的n層數據訪問模式，但它也需要大部分工作。

您可以通過使用基於約定的映射（如AutoMapper）來解決映射中的一些問題。

當涉及到類爆炸時，是否會使用過於平坦的數據結構？

這可能很難說，因爲DTO自然包含大量的語義重複，結果根本不是邏輯重複。例如，即使您有語義上相似的類型，如果其中一個是ViewModel，另一個是域對象，它們可能會共享語義結構，但具有完全不同的職責。

另一方面，如果您在同一個應用程序層（例如UI）中有大量的重複，則可能違反了DRY原則。在這種情況下，通常可能有助於將相關數據封裝在以平面數據結構開始的獨立類中。在我知道的大多數UI框架中，您仍然可以將平面顯示器綁定到分層結構的類。

Answer 2

類爆炸的問題是DTO方法固有的問題，對此你可能做的不多。注意不要將視圖模型與DTO模型混合使用。您的DTO應該只用於從您的數據層獲取數據到您的前端，而不是用於演示。

隨着.NET 3.5的出現，你可以選擇實現一些基本的，更粗粒度的DTO，並用匿名類型替換你的ViewModel，你可以動態創建你的DTO。我發現這是一個非常靈活的解決方案。

關於您的命名約定，將您的DTO分組到場景並將其放入相應的命名空間中可能很有用。例如Solution.AssetManagement.Asset和Solution.AssetReporting.Asset