我一直在学习 ASP.NET 的一些新功能，超出了我目前的舒适程度，并且我正在尝试从设计的角度准确地弄清楚自定义事件如何适应。我知道它们是如何工作的，以及观察者/订阅者模式，但似乎自定义事件并没有太多讨论。看起来整个应用程序可以通过在各处注册事件和响应来构建，但是，我们看到更多 Controller 类型的类以预定的模式触发代码位......它是 OOP，但仍然有点像程序。
那么从设计的角度来看，什么时候最好使用事件？它们是否在某些场景下非常方便，但在其他场景下却没有什么用处？或者是否有可能创建一个严重依赖它们的应用程序，并且程序员可以随意使用它们？
大多数情况下，我只是好奇它们在哪里属于“正确”的设计，因为我可以轻松地重新想象我的一个或两个应用程序更多地依赖它们，而不是在按下按钮时触发 Controller 类逻辑被点击。
最佳答案
您在 ASP.NET 代码中看不到那么多自定义事件，主要是因为可以触发“事件”的事情往往是用户通过内置控件之一(如按钮或按钮)在客户端上执行的操作。不是什么。服务器本身并不真正与代码“交互”，因为它以事件驱动的方式执行。
您可以通过常规控件之一获得回发。服务器上的执行本质上往往是非常程序化的......这正是在像 Web 这样的无状态请求/响应环境中最有意义的模式。
asp.net 页面生命周期和服务器控件都公开了许多事件，并且可能会触发那些类似 OO 的方面，这些方面实际上只是支持其本质上的高度过程化和线性执行路径。
自定义服务器控件像内置控件一样公开自定义事件，以便页面开发人员拥有一种可以与控件交互而无需紧密耦合的机制...因此您可以在其中找到大多数自定义事件。但是，只有当您确实有许多可能使用该控件的不同页面时，制作自定义服务器控件的成本才真正值得。
我也经常在用户控件中使用事件。虽然您可以将用户控件与服务器控件非常相似地对待，但通常用户控件在 OO 设计原则方面往往比较薄弱。对于用户控件，您通常只是试图获得一点关注点分离和一些封装，但您往往在托管页面和用户控件之间仍然具有相当紧密的耦合。但是，有时用户控件可能需要向托管页面发出信号，表明某些条件已满足，在这些情况下，自定义事件是处理该信号的好方法，比直接调用托管页面上的方法具有更少的耦合。
关于asp.net - 您多久使用一次自定义事件？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/509156/