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