DTOs與序列化持久實體

Question

我很想知道社區對此主題的感受。我最近遇到了一個N​​Hibernate/WCF場景（實體持久存在於服務層）的問題，並意識到我可能會在這裏走錯方向。

我的問題很明顯，當在Web服務（本場景中的WCF）後面使用持久對象圖（NHibernate，LINQ to SQL等）時，您更喜歡通過電線發送這些實體嗎？或者你會創建一組更輕的DTO（無循環引用）？

Answer 1

DTO。使用AutoMapper進行對象到對象的映射

Answer 2

我幾乎總是創建dtos來通過線路傳輸並在我的服務器和客戶端上使用richter實體。在客戶端，他們將擁有一些常見的表示邏輯，而在服務器上他們將擁有業務邏輯。 dtos和實體之間的映射可能是愚蠢的，但它需要發生。像AutoMapper這樣的工具可以幫助你。

Answer 3

如果您問我是否將序列化實體從Web服務發送到外部世界？那麼答案肯定是否定的，如果你這樣做，你將獲得最小的互操作性。 DTO通過定義一組「對象」來幫助解決這個問題，無論您使用的是C＃，Java，Javascript還是其他任何語言，都可以用任何語言實例化這些對象。

Answer 4

我以前曾經多次出現過這種情況，可以從雙方的經驗談起。最初我只是序列化我的實體並按原樣發送它們。從功能的角度來看，這樣做很好，但我越是仔細研究它，就越意識到發送的數據比我需要的要多，而且我失去了改變任何一方的實現的能力。在後來的服務應用程序中，我創建了DTO，其唯一目的是從Web服務中獲取數據。

任何互操作性之外，不必考慮所有正在通過網絡發送的領域是非常有幫助的（對我來說），以確保我不發送是不需要或者更糟的數據，不應該下到客戶端。

正如其他人所提到的，AutoMapper是實體到DTO映射的一個很好的工具。

Answer 5

我一直有問題通過電線發送nHibernate對象。特別是如果你使用ActiveRecord模型。和/或如果你的對象與會話有關係（yuck）。另一個令人討厭的結果是，nHibernate可能會嘗試在方法的入口處加載對象（在你可以到達之前），這也可能導致問題。

所以...在這裏得到消息？問題，問題問題... DTO的一路