Silverlight驗證機制主要內容分析
Silverlight開發工具主要應用于多媒體方面，可以幫助開發人員實現多平臺的音頻視頻處理，創建出一個適合開發需求的WEB應用程序。我們將會在這篇文章中針對Silverlight驗證機制做一個詳細的介紹。#t#
我們在項目中使用了Silverlight驗證機制。一開始，感覺很不錯：可以用標注的方式聲明驗證邏輯，自動設置校驗控件，自動驗證數據——一切似乎很好。但是很快我發現，Silverlight的校驗機制也是存在嚴重限制的。
對于不熟悉Silverlight驗證機制的朋友，我可以在這里作一個簡單的介紹。關鍵在于System.ComponentModel.DataAnnotations這個程序集，它提供了一些標記屬性，你可以為實體添加這些標記，然后在編寫實體讀寫方法的時候添加一些觸發校驗邏輯的樁代碼，那么內置有數據校驗功能的控件（比如Label和DataForm等）就能自動識別、并按照你設定的值來進行校驗。
下面是從Pro Silverlight 3 for C#中摘抄的一段代碼。即使不看手冊，其中Silverlight驗證機制規定的驗證邏輯是很容易看懂的。
- [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驗證機制看起來很簡單，而且我們使用的開頭一段時間內運行得也相當不錯，省去了很多手工校驗的工作。直到有一天我們創建了某個新實體的時候，麻煩來了。
問題是這樣的，項目需求要求我們保存某些客戶信息，其中Email是必須填寫的。實現此邏輯只要為屬性加上一個Required標注即可。但問題在于，盡管Email是必須填寫的，但我們卻無法為它提供一個合理的默認值，所以開始的時候此屬性是空字符串。另一方面，這個實體最初是從服務器端通過序列化得到的，而進行序列化和反序列化的時候也會調用Setter，從而調用校驗邏輯，拋出異常——這是我們不希望的行為。雖然不希望，我們卻不能去掉它，如果去掉的話，那么Silverlight的校驗邏輯就不能工作了！
此問題的關鍵點在于，序列化的時候需要調用實體的Setter，界面綁定的時候也要調用Setter，但兩種情況下需要的行為卻是不同的。創建一個新實體的時候，其中某些屬性有可能是無效的，但我們并不能因此阻止用戶創建新對象，這時候是應當禁用驗證邏輯的。 那么接下來的問題就是，實體的Setter中能不能識別到是在哪一種情況下調用的，從而打開或關閉驗證呢？
開始我想到了Environment.StackTrace，根據調用堆棧來判斷運行環境，應該可以識別出代碼運行的場合。但是實驗一下就發現：此路不通。StackTrace這個屬性在Silverlight版本的CLR中是根本沒有提供的，于是這個方向被堵死了。
有的組員提出，是否可以設置一個提示性的初始值，比如“<請填寫>”？這個建議很快被否決了，因為要求用戶來刪掉無效的值再重新輸入并不合理，也不友好。
然后又有人說，是否可以根據實體的Id來判斷，如果是0則表示是新建的對象，不需要校驗？ 這也是不可行的，因為新建的對象在提交的時候同樣需要校驗。
當然還有一個辦法是為界面綁定和數據傳遞分別生成兩套實體，一套有數據校驗，一套沒有，然后寫代碼來在它們之間進行轉換。但是想想也可以知道，這樣工作量實在太大了，也增加了維護的難度。
最終我們采取了一個比較笨的辦法：為實體添加一個IsUIBinding標志，一開始為false，在綁定到界面之前設置為true，提交服務器之前再復原為false。這樣是可以解決問題了，不過程序員的負擔就更重了——必須記住在合適的時候修改這個標記，否則程序就會出現bug。
這個結果讓我對Silverlight驗證框架感到有點遺憾。Silverlight的驗證方法過于嚴格——一旦數據不合法，ValidationException就會拋出，于是所有后續代碼都無法執行，如果運行環境沒有做好處理此異常的準備的話，那么整個程序都會出錯。而其他的場景——比如序列化的時候是沒有辦法處理此異常的，這大大限制了校驗機制的應用場景。
其實從設計上看，Silverlight驗證機制使用了ValidationResult來收集校驗失敗信息，那么理論上講，不使用異常，而根據ValidationResult收集的結果來判斷也是完全可能的。但最終Silverlight還是采用了異常的方法。不過盡管有此遺憾，Silverlight的校驗機制對于一般的數據驗證還是不錯的，目前我們也不太可能拋開它去完全實現一套自己的校驗方法，只有在編程的時候多加注意了。
