微軟技術系列(WebForm)

在傳統型程式和BS應用程式比較來看,無論是開發速度還是使用者體驗來說,都是傳統型程式要有優勢.由於BS程式的特性,使得在開發BS程式時可使用的資源非常有限(用戶端只能藉助瀏覽器，用戶端與服務端的無狀態互動，服務端的集中計算壓力等），因而也嚴重影響了BS程式開發的效率。怎麼讓BS的開發能像案頭開發那樣富有效率，一直以來也是業界的追求。微軟的WebForm就是這樣一種嘗試，而且取得了一定的成功。Webform在傳統的html,css,javascript+服務端基本互動對象(Request,Response,Server,Session,Application)上，利用反射和對象序列化技術，成功地將BS程式開發有了傳統型程式開發的體驗：拖放控制項，所見即所得 (WYSIWYG)，表單事件等。當然，離真正的案頭開發還是有距離的，不過這已經是非常了不起的進步。Webform的出現和能成功應用，其實也得利於互連網速度和頻寬的改善。

WebForm是建立在已有的Web開發技術之上，只是充分利用了已有的技術，並不需要在瀏覽器端，或者是瀏覽器—應用伺服器之間增加額外的構件，因此，WebForm一如既往的秉承了Web程式的風格和優點。我們知道，傳統型程式的開發之所以體驗非常好，主要得益於用戶端資源的豐富和天然的狀態保留功能，用戶端和服務端只需要互動變化的那部分資料或者狀態資訊，而大部分的，特別是介面上的狀態則不需要特別的處理。因此，Webform能類比到這種類似案頭開發的程度，付出的代價也非常大，主要在以下幾個方面：
     1，為了保持頁面表單的狀態，Webform增加了ViewState,而這個ViewState是要在用戶端與服務端來回傳遞的，因此無疑的增加了網路流量，同時也使得資料安全成為一個潛在的風險和問題；
     2、頁面的重建代價非常大。服務端頁面及控制項屬性非常多，這些屬性要保持狀態就必須序列化後儲存在ViewState中，然後等傳回來時在利用還原序列化來恢複原來的狀態，其過程如下：伺服器頁面處理完成前，將要保持狀態的控制項資訊序列化，儲存在ViewState中，用戶端傳回後，先建立一個新的頁面及其相應的控制項，然後利用還原序列化，把從用戶端傳回的ViewState資訊重新賦給對應控制項。如果業務稍微複雜點，頁面控制項多點，這種反覆重構對服務端的壓力就非常大。雖然微軟也提供了關閉ViewState的功能，但說實話，如果你關閉了ViewState，也就失去了選用WebForm的絕大部分意義。
    3、無法完全達到案頭開發的體驗，有很多在案頭開發很容易實現的功能，在這裡需要花費很大的心思和工作量，而且效果還差強人意，比如線上編輯那種。
     Webform的這些缺陷，也是很多人選擇放棄使用的原因。特別是在一些對效能要求非常高的應用情境中，在互聯頻寬和速度還無法與區域網路媲美的情況下，這些代價都是不可承受的。我就經曆過這樣的放棄，我們做的公用平台的CRM，開始採用的就是Webform.但由於我們的系統地體驗和互動都是按照傳統型程式那樣要求，那麼多的頁面元素下還要實現拖放效果，難度可想而知，當然其結果也很直接，不僅不好看，速度也非常慢，後面沒辦法，中途只好轉到silverlight 上去了。
      當然，也不是說Webform一無是處，而且未來的BS開發還會朝著WebForm想要達到的目的發展。而且在很多對效能和互動要求不是特別高的地方，Webform還是有用武之地的。
       微軟其實也看到了WebForm的不足，所以就有了後來的Silverlight和MVC.但不管怎樣，WebForm都可以看做是BS程式開發的一種偉大的嘗試。