我一直在学习ASP.NET的一些新功能，超出了我当前的舒适程度，并且我正在设法弄清楚自定义事件如何适应，从设计的角度来看。我知道他们是如何工作的，以及观察者/用户模式，但是似乎自定义事件并没有被讨论太多。看起来整个应用程序可以通过在整个地方注册事件和响应来构建，然而，我们发现更多的控制器类能够以预定的模式激发代码位......这是OOP，但仍然有点类似程序。你多久使用自定义事件？
所以从设计角度来讲，什么时候最好使用事件？是否有某些情况下他们非常方便，但没有其他的东西？或者是否有可能创建一个严重依赖它们的应用程序，程序员可以根据需要尽可能多或少地使用它们？
大多数情况下，我只是好奇它们落入“正确”设计的位置，因为我可以很容易地重新想象一个应用程序或两个更靠在他们身上的应用程序，而不是仅仅在控制器类逻辑按钮被点击。
你没有看到在asp.net代码尽可能多的自定义事件，主要是因为可以触发一个“事件”的东西往往是事物的用户通过内置控件的人做在客户机上像一个按钮或什么不是。尽管服务器本身并不与代码“交互”，但它以事件驱动的方式执行。
您通过常规控件之一获得回传goind。在服务器上的执行往往本质上是非常程序化的......这只是在像Web这样的无状态请求/响应环境中最有意义的模式。
的asp.net页面生命周期和服务器控件都有很多他们揭露的事件，可能火象方面的OO其实只是支持的是其本质高度程序和线性的执行路径。
自定义服务器控件公开自定义事件就像内置控件做到让网页开发者有一个机制，使它们可以与不紧耦合控制交互......所以这是在那里你会发现大多数的自定义事件。但是，如果你确实有很多不同的页面可能会使用控件，那么制作自定义服务器控件的成本确实是值得的。
我也经常在用户控件中使用事件。虽然您可以将用户控件与服务器控件非常类似，但通常用户控件在面向对象设计原则方面往往很薄弱。通过用户控件，通常只是试图获得一点关注点和封装的分离，但是在托管页面和用户控件之间仍然会有相当紧密的耦合。但是有时用户控件可能需要向托管页面发信号通知某些条件已被满足，并且在这些情况下，自定义事件是处理该信号的好方法，其具有比直接调用托管页面上的方法更少的耦合。
大多数情况下，我在构建自定义控件时使用自定义事件。
在ASP.Net我不使用自定义事件的威力，因为即使有自定义控件我试着更多地依靠现有的页面生命周期。
在Windows窗体几乎所有我做的是抽象成一个控制的地方，所以我使用它们相当多。
我在ActionScript 3.0中做了很多自定义事件。我提到这一点是因为它的委托系统与.NET非常相似。
我正在创建一个可以一次排队多个剪辑的SWF播放器。我的自定义时间轴控件会触发ClipEnd事件，我的主应用程序会监听并推进播放列表。如果用户进入新剪辑或自动执行应用，我的播放列表会触发NewClip事件。我的应用程序会听这些并告诉时间轴开始播放下一个剪辑。所以我的时间轴和播放列表通过自定义事件共享链接。