2012-08-09 70 views
3

我明白我的DDD模型項目should be totally isolated並沒有引用我的應用程序的任何其他層,並且我的WCF服務將包含帶有WCF服務所需的所有特殊屬性的真實模型對象的DTO版本。該服務還將參考模型並知道如何translate between the DTO and "real" model objects客戶端應用程序應該使用實型模型類還是DTO對象與WCF服務通信?

我想知道的是,使用DTO對象或真實模型對象的客戶端應用程序是否需要使用此服務進行通信?客戶端應用程序是否應該負責將從服務接收的DTO對象轉換爲模型版本,還是應該將其構建到服務中,以便客戶端不直接處理DTO對象?

我正在考慮創建一個封裝類來包裝服務的一個實例,並公開相同的功能,但作爲模型對象而不是DTO版本。好主意?餿主意?

回答

2

WCF不理解'真正的模型類',它只能理解DTO。客戶端代碼必須以某種方式理解這些DTO(或序列化的有效載荷)。所以你的問題是你是否可以使用來自客戶端和服務器的相同的域模型類。

我正在考慮創建一個封裝類,它封裝了一個服務的實例,並公開了相同的功能,但作爲模型對象而不是DTO版本。好主意?餿主意?

這取決於您正在構建什麼類型的應用程序以及您有哪些部署限制。

直接從客戶端和服務器引用域對象意味着您將不得不同時升級它們。如果您的「用戶」實體例如具有「名稱」屬性,並且您決定將其分爲「第一」和「最後」,則需要同時更新客戶端,服務器和數據存儲。這只是一個簡單的例子,模型行爲的變化可能會更成問題。如果您準備在發生某些變化時重新部署整個堆棧,則您的方法似乎可行。在這種情況下,您甚至可以嘗試避免使用「包裝器」,並嘗試將此代碼作爲替代存儲庫實現。換句話說,您可以嘗試擁有兩個存儲庫實現:一個用於客戶端,另一個用於服務。客戶端存儲庫實現將使用WCF服務作爲基礎數據存儲。服務使用的存儲庫實現將使用實際的數據存儲。

另一方面,將客戶端與服務器上的更改隔離開來可能是一個好主意。在這種情況下,您的主域模型僅由服務引用,並作爲客戶端特定的DTO向客戶端公開。這樣,您就可以自由地發展您的域模型和服務代碼,而不會影響客戶端。如果您願意,客戶端可能會擁有自己的模型類版本,即「子模型」,它將根據從服務器接收的DTO進行填充。

相關問題