微软技术系列(WebForm)

在桌面程序和BS应用程序比较来看,无论是开发速度还是用户体验来说,都是桌面程序要有优势.由于BS程序的特性,使得在开发BS程序时可使用的资源非常有限(客户端只能借助浏览器，客户端与服务端的无状态交互，服务端的集中计算压力等），因而也严重影响了BS程序开发的效率。怎么让BS的开发能像桌面开发那样富有效率，一直以来也是业界的追求。微软的WebForm就是这样一种尝试，而且取得了一定的成功。Webform在传统的html,css,javascript+服务端基本交互对象(Request,Response,Server,Session,Application)上，利用反射和对象序列化技术，成功地将BS程序开发有了桌面程序开发的体验：拖放控件，所见即所得，窗体事件等。当然，离真正的桌面开发还是有距离的，不过这已经是非常了不起的进步。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程序开发的一种伟大的尝试。