詳解WCF中的變更處理：不可不知的最佳實踐
譯文【51CTO快譯】變更總是存在的，包括需求變更、環境變更和過程變更。這些因素加在一起使你的WCF服務也會發生變更，幸運的是，可以在設計之初就采取一些方法來盡量避免這些變更，或者說減少變更給用戶和自己帶來的影響。
本文探討的不僅僅是前期如何做才能減少變更次數，同時還討論了在遇到未曾預見的大型變更前該如何應對。
51CTO編輯推薦：WCF開發基礎專題
確定變更
在開始著手處理變更之前，有必要弄清楚在基于WCF的服務中發生變更意味著什么，下面的行為構成了變更：
1、數據契約
（1）增加一個數據成員
（2）移除一個數據成員
（3）重命名一個數據成員
（4）改變數據成員的類型
2、服務契約
（1）增加一個操作
（2）移除一個操作
（3）重命名服務契約
3、操作契約
（1）重命名一個操作
（2）修改操作的簽名
這些變更可能源于新的業務需求、硬件整合、業務兼并、新條例或任何其它外部因素，底線是當某些東西超出了開發人員的控制變更外，軟件就必須要調整，在WCF世界中處理變更總是有好消息也有壞消息，因為有時候處理起來很簡單，但有時候會讓你懼怕，但卻不得不響應。
WCF中的版本和變更控制
在.Net世界中，處理變更時第一個要考慮的就是如何控制版本，通過版本組裝，可以在后續的組件版本中允許無法預料的或有問題的變更，使用這種方式，受影響的客戶端可以繼續使用舊版本，你就可以避免因變更引起的頭痛問題。
那么WCF支持版本控制嗎？答案有點擔憂。當你在WCF中創建一個數據契約時，這個契約會生成一個XML schema，引用這個schema的用戶使用它生成一個代理類，嚴格地說，數據沒有經過這個schema驗證，正如你將看到的，這將對服務使用者產生一些異常或令人沮喪的行為。
在進入細節前，仔細研究下面例子自己先熟悉一下，它提供了本文剩余部分討論的基礎：
namespace SampleService
{
[ServiceContract]
public interface IPersonService
{
[OperationContract]
Person GetPerson(int personId);
[OperationContract]
void UpdatePerson(Person p);
}
public class Person
{
private string _firstName = string.Empty;
private string _lastName = string.Empty;
[DataMember]
public string FirstName
{
get { return _firstName; }
set { _firstName = value; }
}
[DataMember]
public string LastName
{
get { return _lastName; }
set { _lastName = value; }
}
}
}
數據契約變更
Person DataContract定義了兩個屬性：FirstName和LastName，如果某個客戶的引用了這個服務，你接著將LastName改為SurName，客戶的不會被真正斷開，只不過在客戶端的代理類中，LastName屬性將會顯示為空，這時因為當客戶的將消息持久化到Person類時，發現沒有任何名叫LastName的元素了。
這個簡單的變更不會讓客戶端出現異常錯誤，但糟糕的是會導致一個異常行為，除非你親自了解每個客戶的應用程序使用的web服務，修改將會是災難性的，作為一名開發人員，你應該盡一切努力來保護變更給客戶帶來的影響。
最初，你可以先應用一些最佳實踐，幫助那些孤立的客戶端應對變更，一個數據契約的升級版本看起來如：
在DataContract和DataMember屬性上增加了Namespace、Name和Order參數來控制DataContractSerializer的行為，引用這些服務時會增加一個客戶端代理，Name參數會導致串行轉換器使用標示的值，而不是真實的公共成員或屬性的名字，這種方法允許在內部實現變更，不影響客戶端，如下面的變更：
[DataMember(Name="LastName")]
public string SurName
{
get { return _lastName; }
set { _lastName = value; }
}
屬性名從LastName變成SurName將會中斷現有的客戶端，因為客戶端使用的Name參數任然是LastName，僅僅內部實現變更了。
第二個顯而易見的變更是增加了IExtensibleDataObject接口，實現這個接口讓未在契約中明確定義的客戶端保留數據，這看起來沒什么作用，但是當客戶端希望在同一個Person對象上執行處理并返回時就有用了，客戶端可以保留新的數據項。例如，使用下面的新成員更新PersonContract不會強制現有的客戶端也跟著一起更新：
[DataMember(Name = "MiddleName", Order = 3)]
public string SurName
{
get { return _middleName; }
set { _middleName = value; }
}
事實上，這個成員將允許現有的客戶端保留一個值放于MiddleName，實現IExtensibleDataObject對于未來你的數據契約是一個好方法，作為一個最佳實踐，你應該在所有數據契約中使用它。
請記住，客戶端實際上可以選擇一個外部schema驗證消息，因此，你在處理數據契約變更時有兩件事需要考慮：有schema驗證和無schema驗證。
當客戶端添加了schema驗證后，數據契約中任何添加、修改或減去數據項的行為都將導致驗證失敗，因此，在實際生活照，試驗了任何嚴格的schema驗證后，契約就不應該改變了，相反，你應該創建一個全新的契約并在契約中使用不同的命名空間，以表明是新版本。
例如，從實現的視角來看，你應該需要兩個獨立的服務點來使這兩個版本可用：
幸運的是，嚴格的schema驗證不是默認行為，這意味著你在不中斷客戶端的情況下可以添加或移除數據成員，然而，根據前面討論過的異常行為，移除一個數據成員不是個好主意，換句話說，增加一個數據成員容易，用戶會忽略他們不知道的額外成員。
最關鍵的是使用DataMember屬性的Order參數，使用這個參數告訴串行轉化器在XML中各個成員應該顯示成怎么樣，一個非預期的變更可能會導致XML與原始schema不一致，從一開始就使用Order參數可以避免這個問題，如果你不使用Order參數，串行轉化器將按照下面的順序執行：
1、來自基礎類型的成員
2、無Order參數的成員（按字母順序）
3、有Order參數的成員（按值的順序）
數據契約變更的最后一種情況是修改數據成員的類型，在這種情況下，最佳的做法是和新的服務契約、實現和終結點一道創建一個新版本的數據契約。
服務契約變更
再說一次，所有服務契約應該按照最佳實踐，在ServiceContract屬性上同時使用Name和Namespace參數，Person服務契約的一個更新版本看起來如：
[ServiceContract(Name="PersonService", Namespace="
public interface IPersonService
和數據契約一樣，使用Name隔離服務用戶和真實接口名，允許內部實現按需變更，Namespace允許你在將來對契約進行版本控制，記住新版本也需要新的終點。
可以在不中斷現有用戶的情況下往服務契約中添加操作，用戶會忽略新增加的操作。另一方面，移除操作將會中斷現有用戶，如同所有的中斷變更，移除操作需要一個新版本和一個新的終點。
操作契約變更
與服務契約和數據契約一樣，應該在OperationContract屬性上使用Name參數：
[OperationContract(Name="GetPerson"]
Person GetPerson(int personId);
再說一次，在內部實現中用戶和變更是隔離的。
最后一個需要考慮的變更是操作契約的簽名，這是一個中斷變更，有兩種解決方案：創建一個新版本或在服務契約上添加一個新操作。
遵守你的承諾
變更是不可避免的，但要做好規劃，并遵循一些原則，可以講WCF服務上變更的影響降到最低，記住，當你發布一個服務時，你應該向用戶提供一個承諾，讓他們保證遵守契約，在現有的契約上做改動不是一件好事。
為此，請記住下面這些最佳實踐：
1、在所有契約上使用Name和Namespace參數；
2、在數據成員上總是使用Order參數；
3、在所有數據契約上實現IExtensibleDataObject；
4、為契約版本控制使用命名空間；
5、記住所有新版本都需要新的終點；
6、使用嚴格的schema驗證時，不要修改契約，創建一個新版本；
7、從服務契約中移除一個操作時，請創建一個新版本；
8、改變一個操作的簽名時，請創建一個新版本。
記住這些最佳實踐后，在處理你自身或服務用戶提出的變更時就會游刃有余了。
原文：Best Practices for Handling Change in Your WCF Applications
作者：Steve Stefanovich
【編輯推薦】
