Silverlight開發(fā)工具主要應(yīng)用于多媒體方面，可以幫助開發(fā)人員實現(xiàn)多平臺的音頻視頻處理，創(chuàng)建出一個適合開發(fā)需求的WEB應(yīng)用程序。我們將會在這篇文章中針對Silverlight驗證機制做一個詳細的介紹。#t#

我們在項目中使用了Silverlight驗證機制。一開始，感覺很不錯：可以用標注的方式聲明驗證邏輯，自動設(shè)置校驗控件，自動驗證數(shù)據(jù)——一切似乎很好。但是很快我發(fā)現(xiàn)，Silverlight的校驗機制也是存在嚴重限制的。

對于不熟悉Silverlight驗證機制的朋友，我可以在這里作一個簡單的介紹。關(guān)鍵在于System.ComponentModel.DataAnnotations這個程序集，它提供了一些標記屬性，你可以為實體添加這些標記，然后在編寫實體讀寫方法的時候添加一些觸發(fā)校驗邏輯的樁代碼，那么內(nèi)置有數(shù)據(jù)校驗功能的控件（比如Label和DataForm等）就能自動識別、并按照你設(shè)定的值來進行校驗。

下面是從Pro Silverlight 3 for C#中摘抄的一段代碼。即使不看手冊，其中Silverlight驗證機制規(guī)定的驗證邏輯是很容易看懂的。

[StringLength(25)]  
[Display(Name = "Model Name", 
Description = "This is the retail 
product name.")]  
public string ModelName  
{  
get { return modelName; }  
set  
{  
ValidationContext context = new 
ValidationContext(this, null, null);  
context.MemberName = "ModelNumber";  
Validator.ValidateProperty
(value, context);  
modelName = value;  
OnPropertyChanged(new Property
ChangedEventArgs("ModelName"));  
}  
} 

Silverlight驗證機制看起來很簡單，而且我們使用的開頭一段時間內(nèi)運行得也相當不錯，省去了很多手工校驗的工作。直到有一天我們創(chuàng)建了某個新實體的時候，麻煩來了。

問題是這樣的，項目需求要求我們保存某些客戶信息，其中Email是必須填寫的。實現(xiàn)此邏輯只要為屬性加上一個Required標注即可。但問題在于，盡管Email是必須填寫的，但我們卻無法為它提供一個合理的默認值，所以開始的時候此屬性是空字符串。另一方面，這個實體最初是從服務(wù)器端通過序列化得到的，而進行序列化和反序列化的時候也會調(diào)用Setter，從而調(diào)用校驗邏輯，拋出異常——這是我們不希望的行為。雖然不希望，我們卻不能去掉它，如果去掉的話，那么Silverlight的校驗邏輯就不能工作了！

此問題的關(guān)鍵點在于，序列化的時候需要調(diào)用實體的Setter，界面綁定的時候也要調(diào)用Setter，但兩種情況下需要的行為卻是不同的。創(chuàng)建一個新實體的時候，其中某些屬性有可能是無效的，但我們并不能因此阻止用戶創(chuàng)建新對象，這時候是應(yīng)當禁用驗證邏輯的。 那么接下來的問題就是，實體的Setter中能不能識別到是在哪一種情況下調(diào)用的，從而打開或關(guān)閉驗證呢？

開始我想到了Environment.StackTrace，根據(jù)調(diào)用堆棧來判斷運行環(huán)境，應(yīng)該可以識別出代碼運行的場合。但是實驗一下就發(fā)現(xiàn)：此路不通。StackTrace這個屬性在Silverlight版本的CLR中是根本沒有提供的，于是這個方向被堵死了。

有的組員提出，是否可以設(shè)置一個提示性的初始值，比如“<請?zhí)顚?gt;”？這個建議很快被否決了，因為要求用戶來刪掉無效的值再重新輸入并不合理，也不友好。

然后又有人說，是否可以根據(jù)實體的Id來判斷，如果是0則表示是新建的對象，不需要校驗？ 這也是不可行的，因為新建的對象在提交的時候同樣需要校驗。

當然還有一個辦法是為界面綁定和數(shù)據(jù)傳遞分別生成兩套實體，一套有數(shù)據(jù)校驗，一套沒有，然后寫代碼來在它們之間進行轉(zhuǎn)換。但是想想也可以知道，這樣工作量實在太大了，也增加了維護的難度。

最終我們采取了一個比較笨的辦法：為實體添加一個IsUIBinding標志，一開始為false，在綁定到界面之前設(shè)置為true，提交服務(wù)器之前再復原為false。這樣是可以解決問題了，不過程序員的負擔就更重了——必須記住在合適的時候修改這個標記，否則程序就會出現(xiàn)bug。

這個結(jié)果讓我對Silverlight驗證框架感到有點遺憾。Silverlight的驗證方法過于嚴格——一旦數(shù)據(jù)不合法，ValidationException就會拋出，于是所有后續(xù)代碼都無法執(zhí)行，如果運行環(huán)境沒有做好處理此異常的準備的話，那么整個程序都會出錯。而其他的場景——比如序列化的時候是沒有辦法處理此異常的，這大大限制了校驗機制的應(yīng)用場景。

其實從設(shè)計上看，Silverlight驗證機制使用了ValidationResult來收集校驗失敗信息，那么理論上講，不使用異常，而根據(jù)ValidationResult收集的結(jié)果來判斷也是完全可能的。但最終Silverlight還是采用了異常的方法。不過盡管有此遺憾，Silverlight的校驗機制對于一般的數(shù)據(jù)驗證還是不錯的，目前我們也不太可能拋開它去完全實現(xiàn)一套自己的校驗方法，只有在編程的時候多加注意了。