WCF數據邊界設計

Question

這更是一個設計問題：

可以說，我有我絕對要保密的一些內部類型定義（不暴露我的服務消費者。然而，我確實需要交流。數據與服務用戶，我想與用戶分享的一些類型與內部類型完全一樣，而另一些類型是內部類型的簡化版本。是否相同對象 - 我主要關心的是內部對象將永遠不會暴露在外面的世界，我的第二個擔心是現在使太多重複代碼...

這個想法是，我真的不想有內部對象的情況被錯誤地暴露在WCF（這只是發生在我身上的，甚至沒有被標記爲[DataContract]內部對象），所以我想到了以下方法：

1. 設計我WCF服務合同文件沒有任何引用內部類型命名空間。 - 這將提供更好的安全性。

2. 在服務實現代碼上實現內部類型及其相應公共代表對象之間的轉換。

這是正確的做法嗎？有沒有更好的解決上述問題的已知模式？

非常感謝， 奧弗

Answer 1

使兩種類型。重複的代碼很糟糕，是的，但是讓你的內部數據和你的DTO不同，並且在它們之間進行翻譯是很常見的。

就我個人而言，我認爲這幾乎是一種最佳做法。

此外，請考慮您的合同，以及是否需要發送整個數據對象或是否只需發出遠程命令。

Answer 2

首先，我想再次向您保證，與服務級別模型相比，在服務實現中有不同的模型是完全可以的。有幾個原因會導致這種情況發生和/或有用，其中兩個是：

• 您不想公開所有實現，但可能只是一個子集。這是你正在描述的場景。
• 您已經找到了一個更好的抽象概念，您希望用於您的服務實現，但對於您的服務的用戶來說這太難理解了。

這兩個原因在我的經驗是有效的，都提供了價值。通過我的團隊，我經常將用作服務級別的模型稱爲「服務級別域模型」。我相信還有其他更好的名字。

使您不想公開的所有類型（接口，類，結構，枚舉）實現它們的程序集。然後創建重複 - 這些可能是DTO（數據傳輸對象）或其他 - 您想要展示的作品，但僅複製數據，而不是實施。取決於實現，您可以使用一些基於反射的巫術來在內部和外部表示之間交換數據。注意可能的性能影響。複製數據是有代價的。

另外，您也可以將數據移到服務客戶端並返回到服務，而不是將數據移動到服務可以執行的操作上。這樣，你首先避免了這個問題。

祝你好運！