DTO/POCO在三級項目中的安置

Question

我一直在爲網站重寫後端，並且一直在將它轉向三層架構。

我的目的是構建這麼：

Web site <--> WCF Service (1) <--> Business Layer (2) <--> Data Layer (3)

我的問題是用的DTO的這個結構中的位置。我需要使用DTO來在業務層和WCF服務之間以及從WCF服務到消費網站之間移動數據。

在我就在這裏的研究，我讀過一些優秀的討論，雖然我已經離開了抓我的頭有點：

• 達維德Piras酒店做一些偉大的點this post如果我是按照這個設計，然後我會在一個單獨的項目中爲POCO聲明接口。這些將由層（1）和（2）實施。雖然我喜歡使用接口，但似乎我會爲自己做更多的工作，方法是在（1）和（2）中聲明POCO，然後使用AutoMapper之類的東西來回複製它們的數據。

• This post使用一個系統，在該系統中創建一個業務對象項目，並由所有層引用。這似乎是比其他解決方案simplier，似乎使我那會是

Web site <--> WCF Service (1) <--> Business Layer (2) <--> Data Layer (3)

^    ^     ^
|    |      | 
[ -- Business Objects Referenced here --] 

我的問題的解決方案是這樣的：有一個代碼味道來自全國各地三層共享業務對象的解決方案還是我上面列出的兩種方法只是兩種不同的方法來破解同一個螺母？

Answer 1

讓我們將您的UI（網站）和服務（WCF + BL + DAL）視爲兩個不同的實體。

• 如果你有超過均爲100％的控制，你應該選擇的辦法＃2，因爲這將避免WCF代理對象，並在用戶界面層業務對象之間的轉換。

• 否則，你最好採用方法1，因爲其中一個實體是一種「黑盒子」，並且可能會受到外部利益相關方的改變。因此，維護一組內部業務對象更爲安全。這將需要您的業務對象和WCF代理對象之間的翻譯（通過擴展方法或翻譯器框架）。

現在，不能完全確定你的UI層的複雜性及其實施（MVC，WebForms的，等等），所以你可能會或可能不會需要查看特定對象（打火機數據綁定，更快的序列化JSON等），我們稱這個對象爲Model。

• 如果你不需要一個獨特的UI特定Model，建議標記您的業務對象爲DataContract（WCF中的上下文中）和跨圖層使用它們。如果您通過Web調用WCF（$.ajax），請不要忘記將實體明確標記爲Serializable。

• 否則，使用DataContract在服務和翻譯到DataContract轉換爲Model在UI層。 A Service Adapter非常適合 - 它位於UI層，負責使用WCF服務並在DataContract和Model之間進行翻譯。您可以在UI層中使用Service Proxy，該層是WCF服務的包裝，可通過網絡使用。

最後，您是不是缺少對數據層中業務對象的引用？我相信您會從數據層本身的數據存儲中填充Business Objects。

Answer 2

我想說，它通常取決於您正在構建的項目的複雜性。對於我構建的小型項目，我在各個層之間共享了我的「實體」（它們只是簡單的DTO，帶有getter和setter的可序列化的數據存儲區），並沒有太在意這一點。最大的缺點是，邏輯分散在整個項目中（不僅在'業務層'中），而且還有一種程序式的風格。這看起來好像是貧血領域模型，但複雜性並沒有隨着項目的增長過多而緩慢增長。實體框架有一些模板可以讓你創建實體（如果我沒有弄錯，他們被稱爲自我跟蹤實體？）。

對於中型/大型項目，我不會使用這種方法，並且會將實體和DTO分開保存，因爲它們將扮演不同的角色。 DTO可能與你的實體有完全不同的形狀，並且試圖在層/層之間共享它們往往是臭的。