ASP.Net的Web服务器控件、Html服务器控件和Html控件

这是关于ASP.Net常被问到的一个问题，很老很老的概念，但也是一个比较容易一知半解的问题。自问了一下，似乎揣着明白说不清楚，于是做点功课整理一下。

首先，为什么会有Web服务器控件、Html服务器控件和Html控件

　　Html控件无需多说，最常用的控件，ASP时代的唯一选择，世界开始的时候它就在那。当微软推出.Net后，为了提供ASP.Net Web Form开发以和Win Form开发相似的开发体验，推出了Web服务器控件（Server Control），又称ASP.Net服务器控件。而Html服务器控件（Html Server Control），则可以看做是为了向下兼容，便于原本基于ASP系统的移植而推出的一种介于Html控件和Web 服务器控件的权宜产物。

Web服务器控件、Html服务器控件和Html控件的区别

• Html控件的标签：<input id="Button" type="button" value="Button" />
• Html服务器控件的标签：<input id="Button" type="button" value="Button" runat="server" />
• Html服务器控件其实就是Html控件的基础上加上runat="server"所构成的控件
• Web服务器控件的标签：<asp:Button ID="Button" runat="server" Text="Button"/>
• Web服务器控件会根据情况在浏览器端产生一个或多个对应的Html标签。

 

• Html服务器控件位于System.Web.UI.HtmlControls
• Web服务器控件位于System.Web.UI.WebControls
• Web服务器控件与Code Behind的Class文件相结合，提供了包含属性、方法和事件的完整对象模型。

 

• Html控件不能在服务器端控制，只能在浏览器端通过javascript等脚本语言操作。
• Html服务器控件设定了runat="server" 属性后，页面对象会将该控件载入控制器，服务器端的代码就能对其进行控制。
• Html服务器控件在页面执行完毕后会被转换成Html标注，然后当成字符串流发送到浏览器端，浏览器端的脚本能够进行操作。
• Web服务器控件的操作则是由页面把Form发回服务器，然后完全由服务器端代码处理。

 

• Html控件的事件处理发生在浏览器端，除非Submit，否则不会发生Postback
• Html服务器控件的事件处理发生在浏览器端。
• Html服务器控件如果要Postback到服务器端，调用服务器端的方法，需要添加onserverclick之类的事件。
• Web服务器控件部分默认为AutoPostback，或者可以设置AutoPostback。

 

• 在产生Postback或是重新生成页面时，Web服务器控件自动保存状态到ViewState。
• Html控件和Html服务器控件需要自己编码实现。

Web服务器控件、Html服务器控件和Html控件的优缺点

• Html控件和Html服务器控件需要编码以保持浏览器兼容。
• Web服务器控件能够检测浏览器的兼容性，保持表现的一致。

 

• Html服务器控件通过为Html控件添加runat="server"以实现ASP程序的移植。
• 将ASP程序移植成使用Web服务器控件的ASP.Net程序相当于重写新的应用。

 

• Html控件和Html服务器控件是标准控件，能够用浏览器端脚本语言操作。
• 使用Web服务器控件提供的对象模型，能够得到和Win Form类似的编程体验，而且无需再学习不同的脚本语言。
• Web服务器内部的代码并不开放，你无法获得比较直接的控制。

小结

　　个人认为，Html服务器控件作为一个过渡的实现，虽然能够兼顾浏览器端和服务器端，终究是一个奇怪的存在，尽量少使用为妙。从微软的角度，良好封装的Web服务器控件提供了大量的便利，同时Web Form和Win Form开发模式的差异使得相互的经验能够互通，当然是多使用Web服务器控件为好。不过Web服务器控件的缺点是占用服务器资源，页面Postback过多（Ajax啊Ajax）。所以现实是存在的就是合理的，Html还是要会地，Javascript当然是要好好学地，Web开发各种奇奇怪怪的标签共存于Page中的场面短时间内是不可能消失地。