正在使用DTO解決此問題的最佳方法？

Question

我在客戶端/服務器系統上工作：

有一個數據庫，一個應用程序服務器和一個用戶界面（客戶端）應用程序。應用程序服務器處理來自客戶端應用程序的連接，客戶端應用程序在客戶端應用程序請求實例的用戶列表或者通過id訪問特定對象時會與數據庫交談。

目前我有一組數據對象，如「用戶」，「區域」等映射到數據庫中的表。這些數據對象是在共享庫中定義的，該共享庫在編譯時鏈接到客戶端和應用服務器。它們繼承了一個允許它們被序列化的類，以便它們可以在客戶端和服務器之間傳遞，並且它們將「數據提供者」作爲依賴注入來允許提交發送到應用程序服務器或發送到數據庫，具體取決於if他們正在客戶端或服務器端使用。

當客戶端應用程序的用戶想要編輯用戶時，它會從應用程序服務器請求該對象，使用它來用當前值填充用戶界面，允許用戶編輯這些值，然後「提交「對象返回到應用程序服務器，然後將其提交給數據庫。

這對於這個非常簡單的場景來說很好，但是隨着它變得更加複雜，用戶界面將需要可能由幾個底層數據庫對象組成的對象，所以我想我需要從數據庫抽象出來模型在一定程度上。

既然如此，我不應該將我認爲會被稱爲「DAL」對象的東西傳遞給用戶界面（通過序列化），所以我想我需要一些DTO（數據傳輸對象）。

我也在應用程序服務中發現業務邏輯，我目前正在處理它全部通過切換從客戶端提交的對象的類型，做任何需要然後提交到數據庫。我想也許在這裏我需要業務對象，而每個對象知道如何驗證和行動。

所以我想也許結束了：

Shared: 
* UserDTO (data transfer object) 

Application Server: 
* UserDAL (data access object) 
* UserBO (business object, contains UserDAL) 
* UserDTO (data transfer object as defined in shared lib) 

Client: 
* UserDTO (data transfer object as defined in shared lib) 

因此，客戶端請求用戶DTO，顯示或更新爲neccessary，「保存」方法被調用，它就會被序列化並送到應用程序服務器對其進行反序列化，創建業務對象，執行任何它喜歡的操作（例如驗證，保存到數據庫等）。

這意味着將所有我的序列化邏輯從DAL對象移除到DTO對象，並刪除我的大型業務邏輯類，並停止表示層（客戶端）必須知道有關數據庫結構的任何信息。

這聽起來是對的嗎？

其他人確實建議在共享庫中擁有業務對象，並且不要有數據傳輸對象。這個問題雖然是我有兩個地方的業務邏輯，它很高興能夠在一個地方更新業務邏輯，而不必更新100個客戶端應用程序與一個應用程序服務交談。這也意味着業務對象也必須具有DTO對象的所有get/set例程。

我希望這是有道理的。任何想法將不勝感激:-)

Answer 1

我最初的想法是 - 你的實際問題是什麼？因爲從我所看到的你沒有做錯任何事情。

是的 - 將多個對象放入一個DTO，然後序列化，以便在客戶端/服務器之間傳輸「通過電線」聽起來正確。

是的 - 有一個共享的類型/業務對象庫是好的;我假設他們不過是沒有邏輯的真正'愚蠢'的數據結構，並且他們不經常改變。

所以我想我需要從某種程度上抽象出數據庫模型。

是的。你可能可以在客戶端和服務器之間做同樣的事情。如果您使用的是Microsoft平臺/ .Net，則可以使用允許使用不同類型綁定的WCF，因此不需要更多的手動序列化。

與這雖然問題是我有2個地方

是havingit在兩個地方是不理想的商業邏輯 - 但它確實有一定的優勢。在客戶端複製一些業務邏輯的一個優點是（我在考慮「驗證」規則），因爲用戶界面可以爲用戶提供更多的交互式體驗，因爲他們不需要等待來回告訴他們不能將他們的姓氏添加到電話號碼字段中。可以這麼說，您仍然會在服務器端提供適當的驗證和完整的業務規則：「縱深防禦」。