我对于事件回发的理解

[minhua1983]

一直觉得学JAVA的看不起ASP.NET（我估计指的就是WEBFORM），觉得ASP.NET程序员只会拖控件。有些培训机构打着“不做只会拖控件的菜鸟”来教学生，也无可是非。

服务器控件是WEBFORM的基础，VIEWSTATE是服务器控件维护状态的依赖，VIEWSTATE则是在页面生命周期上使用和维护的，而页面生命周期又是整个WEBFORM机制的核心。所以想学好WEBFORM，建议最好学一下自定义控件开发。我就学了2个自定义控件，第一个是继承CONTROL来做一个能引起回发的自定义BUTTON，继承Control，重写Render方法，实现IPostBackEventHandler.RaisePostBackEvent方法，定义MyClick事件，这些对于初学者都不好理解，很多初学者都是知其然，却不知其所以然，当然我也是死背，却不知道为啥要这样。第二个是继承CONTROL来实现自定义REPEATER，也差不多，不再重写Render方法，而是重写OnDataBinding和CreateChildControls方法，通过VIEWSTATE维护控件的复杂属性（需要实现IStateManager），等等。但是麻烦的是必须知道在合适的时候做合适的事，如何时LOAD控件VIEWSTATE，何时SAVE控件VIEWSTATE。这样你就必须对页面生命周期需要有清楚的了解，不然你都不知道该重写那个方法。

举个简单例子，就拿Button控件来说，大家都知道在VS设计视图下，双击Button会在页面自动生成ButtonId_Click(object sender,EventArgs e)方法。但是很多新手不知道为什么当我运行页面时点击这个按钮为什么会调用这个ButtonId_Click方法。

其实按了Button后页面进行回发，在页面Load阶段后，是RaisePostBackEvent阶段，页面会根据是哪个控件引起的回发，则调用这个控件的RaisePostBackEvent方法。Button控件正是实现了IPostBackEventHandler.RaisePostBackEvent方法，而Button控件又定义了Click事件，控件内部会对应自动定义一个叫OnClick的方法，这个方法就是在实现IPostBackEventHandler.RaisePostBackEvent方法时调用的，在OnClick的方法中，会判断Click事件是否被页面注册过，如果注册过，则调用Click()，而Click正是指向页面的ButtonId_Click方法。

上述例子也就是我对页面事件回发的理解，如有不对之处，请懂的朋友指点下。

[金色海洋]

在以前，webform的开发效率确实不错，这也是他唯一的亮点。 但是时代进步了呀，各种UI都成熟了，客户端配置也强大了（跑js不需要很长的时间），成套的开发方式也越来越多， 开发效率只会越来越快，用不用webform没啥影响了。

[走出一条新道路]

额，楼主的解释还是有点深度的，我个人只知道服务端控件最终被解析为HTML的，就像你说的Button，服务器端的Click我是不明白，我只知道它会变为HTML的OnClick

[zhanglong_longlong]

只看，，不语

[金色海洋]

最强大的地方，同时也是最大的弱点。 webform的服务器控件印证了这句话。 服务器控件确实很强大，但是想驾驭好他确实也不容易。 睡着时间的推移，他的弱点也越来越明显 —— 运行效率太低。 服务器控件，大多是用来显示数据，比如GridView、Repeater等。 那做mis这类的系统的时候，更好的选择是啥呢？各种UI（比如easyUI、extJs等），相比较的优点是啥呢？ 各种UI在呈现数据的时候，完全不占用服务器的资源，而服务器控件是要在服务器上面运行，势必占用服务器的资源。 所以，常用打算，好好看看各种UI吧。webform迟早会被淘汰的。

[ztszhq]

[天殇月痕]

引用 2 楼 u010793151 的回复:

最强大的地方，同时也是最大的弱点。 webform的服务器控件印证了这句话。 服务器控件确实很强大，但是想驾驭好他确实也不容易。 睡着时间的推移，他的弱点也越来越明显 —— 运行效率太低。 服务器控件，大多是用来显示数据，比如GridView、Repeater等。 那做mis这类的系统的时候，更好的选择是啥呢？各种UI（比如easyUI、extJs等），相比较的优点是啥呢？ 各种UI在呈现数据的时候，完全不占用服务器的资源，而服务器控件是要在服务器上面运行，势必占用服务器的资源。 所以，常用打算，好好看看各种UI吧。webform迟早会被淘汰的。

开发效率上webform还是一定优势的····淘汰也不至于

[以专业开发人员为伍]

深入学习asp.net组件开发的人，应该读一读Page的整个过程处理（MainProcess）的源代码，以及当一个控件动态加入控件树的时候的处理的源代码。其实结合一遍Page生命周期控制的那一个过程的源代码，就能基本了解asp.net webform的全貌。 我们聊两句历史和对趋势的分析（其实已经不是什么趋势了，而是残酷的现实）。 asp.net曾经是一个伟大的艺术工具（我是说2001~2005那个时期），但是随后就逐渐成为鸡肋了。 如今直截了当地支持丰富的UI控件的轻量RIA框架也有很多，例如ExtJs和JQuery easyUI等等，这些都是些非常简单的两三行javascript代码和json数据就能立刻产生复杂的预定义交互界面的。 大概在2007年的时候，我期望asp.net能够向更加激进（当时来说是，现在早就不是激进而是普通了）的Ajax过渡，它的所有服务器控件都应该提供一套纯粹运行在浏览器端的版本，也就是说绝对不需要再在asp.net服务器端针对任何界面控件设计程序逻辑。可惜asp.net项目组却拾人牙慧地去抄袭Struts而搞什么成事不足败事有余的asp.net mvc，而放弃了微软一贯抢占“所见即所得的ide界面设计开发环境”霸主地位的那个传统。 那么回过头来看所谓“事件回发机制”，它放在2002年是非常伟大的艺术工具。放到今天，还是一遍遍刷新html到客户端，完全无法适应这个web2.0时代。实际上7、8年前就已经彻底落后于web 2.0了。我真的为asp.net感到惋惜，为微软2006年以后在软件开发平台技术方面每况愈下的情况感到惋惜。 微软公司如果是一个人的话，从一个具有霸气兼容性的优秀程序架构师，逐渐变为一个三流的大众消费品推销员了。

[以专业开发人员为伍]

引用 6 楼 a01589 的回复:

额，楼主的解释还是有点深度的，我个人只知道服务端控件最终被解析为HTML的，就像你说的Button，服务器端的Click我是不明白，我只知道它会变为HTML的OnClick

简单说，楼主说的就是 IPostBackEventHandler 机制。

[以专业开发人员为伍]

能够“简单方便地拖拉控件来开发应用”是非常伟大的艺术工具，我深信这个道理。作为专业开发人员，他应该学会开发大量支持这种开发平台的组件，发布给自己的团队和别人去使用。业余开发人员去使用别人的这类控件，而专业开人员可以开发这类控件，产品经理可以更好地协调美工、交互界面开发工程师、程序工程师这三类人，这就是很好地。 所谓培训机构的那种追逐时髦雷人口号的做法，结合到他们一贯以“肤浅”为根本的办学理念，其实我们也根本没有必要太纠结。我们千万不要让培训学校来忽悠着、让他们的广大学员来取代我们对于受过正规教育的学生们的信心。 也许这会得罪许多培训学校的学员，但是这其实是为了大家好。

[joyhen]

一切的一切都是基于事件驱动机制。 为什么有生命周期这一概念（不管是控件的生命周期还是页面的生命周期），那是因为在不同的过程阶段会有不同的消息。 拿button为例，它有一个事件叫单击，当单击发生时，button会发布一个消息“我被单击了”；在这之前关心这个问题的类会跟这个事件注册一下，就是说我订阅你的消息，当你事件发生时，这个消息要给我知道。而当订阅者知道事情发生了它就会采取相应的处理也就是调用自己预先写好的事件处理方法。 而整个的一个过程，从控件（页面也一样）被渲染解析到事件结束一共跨度了很多个“订阅”-“监听”-“触发”的过程，这些过程的状态特性都会不一样。而生命周期正是对这一抽象的window驱动机制做了一个宏观上的划分，以方便我们“具象”的理解和处理

[走出一条新道路]

引用 9 楼 sp1234 的回复:

能够“简单方便地拖拉控件来开发应用”是非常伟大的艺术工具，我深信这个道理。作为专业开发人员，他应该学会开发大量支持这种开发平台的组件，发布给自己的团队和别人去使用。业余开发人员去使用别人的这类控件，而专业开人员可以开发这类控件，产品经理可以更好地协调美工、交互界面开发工程师、程序工程师这三类人，这就是很好地。 所谓培训机构的那种追逐时髦雷人口号的做法，结合到他们一贯以“肤浅”为根本的办学理念，其实我们也根本没有必要太纠结。我们千万不要让培训学校来忽悠着、让他们的广大学员来取代我们对于受过正规教育的学生们的信心。 也许这会得罪许多培训学校的学员，但是这其实是为了大家好。

P哥说的不错，培训机构的办学宗旨是3个月上手ASP.NET或者Java等等等等，只教会了学生怎么去“用”，而没有让学生真正理解这些东西背后的技术支持。也许这个就是培训机构的不足和.NET程序员不值钱的原因，还是得靠自己去不断学习，不断摸索