使WCF解串器轉換寬容

假設我有一個C＃Web應用程序和C＃WCF服務漂浮在某處。他們經營這樣的合同：使WCF解串器轉換寬容

[ServiceContract] 
public interface IRemoteDeliveryService 
{ 
    [OperationContract] 
    Customer GetCustomer(); 
}

...與顧客產生：

[Serializable] 
public class Customer 
{ 
    public string Name { get; set; } 
    public int Age { get; set; } 
}

現在假設Web應用程序與一個特點，就是不相關的WCF服務，但是更新的原因客戶需要擴展。

[Serializable] 
public class Customer 
{ 
    public string Name { get; set; } 
    public int Age { get; set; } 
    public int Income { get; set; } // new! 
}

從經驗來看，如果服務引用和服務並不會立即更新，用戶將直到WCF服務推以反映新的對象開始收到此錯誤：錯誤在第1個位置21175.「結束元素」 '（無論）'來自命名空間'http://schemas.datacontract.org/2004/07/(whatever 2）'不是預期的。期待元素'_whatever3'。'

我已經做了所有我能想到的，以避免這種情況。我刪除了一些複雜對象的依賴關係，但是一些（比如Customer）非常重要，它們很難完全取消WCF通信。我已經嘗試阻止序列化的屬性，但WCF無論如何做。

我能做些什麼使WCF服務更加寬容由Web應用程序引入未來的額外屬性嗎？我可以修改服務和Web應用程序，只要修改服務可以最大限度地減少未來的重新部署。

來源

2013-09-23 spamguy

您是否嘗試過使用'interface'作爲契約類型而不是'Customer'實現？ – mrtig

我的經驗主要是使用'[DataContract]'裝飾數據契約，每個數據成員都用'[DataMember]'裝飾，這似乎允許添加沒有問題。 – zimdanen

JSON服務對此非常靈活（如果可能的話）。 JSON序列化器真正序列化消息，無論它包含什麼。 – lcryder

使用數據傳輸對象（DTO）。這些類應該屬於該服務，只應在服務更新時纔會更改。使用類似AutoMapper的東西將業務對象，實體，模型等映射到您的DTO中。

分離圖層（並確保圖層不會互相滲透），將允許您在不影響其他圖層的情況下進行所描述的更改。

來源

2013-09-23 19:33:41 cadrell0

因此，要回到手頭的例子，我會創建第二個客戶類與我需要的所有屬性？我想這就是我一直在做的事情（見底部的第三段）。一個類是幾十個屬性很長，並使用其他類，我將不得不重複這個過程 - 我只是想要一個更簡單的解決方案。我將研究AutoMapper。謝謝！ – spamguy

使WCF解串器轉換寬容

回答

相關問題