删除处理对象时的处理程序
我可以想到一些解决这个问题的方法，但是我觉得应该有一个比我已经提出的更优雅的解决方案。
对象在被处置之前清除其所有事件处理程序的最合适方式是什么。 遗憾的是事件处理程序无法枚举。
理论上，对于将处理程序添加到对象以记住删除它的代码，假设对象在超出范围之前将自行清理，是否更为正确？
理论上，对于将处理程序添加到对象以记住删除它的代码，假设对象在超出范围之前将自行清理，是否更为正确？
对于上述问题，我必须说是。 关于事件的基本理论是事件消防员不应该负责管理自己的处理程序; 无论谁添加该事件都应该进行清理。
有一种方法可以避免事件的这个常见问题 – WeakEvent模式 。
在我的设计中，我非常严格地定义合同，例如：
- 每个资源获取必须与发布配对
- 每次启动服务的呼叫都必须与停止服务的呼叫配对
- 附着在主体上的每个观察者都必须分离
- 等等
（此类合同并不罕见，例如您必须将文件的打开和关闭配对，或者使用不使用自动垃圾收集的语言配对新/删除调用）。
这些合同中的每一个都可以在某种程度上在运行时进行测试。 例如，可以检测并报告分离次数超过其附着的观察者（根据情况断言或例外）。
所以，你的问题是：
理论上，对于将处理程序添加到对象以记住删除它的代码，假设对象在超出范围之前将自行清理，是否更为正确？
是现货。 答案是肯定的，不仅在理论上，而且在实践中也是如此。 在我看来，这些合同可以帮助您避免地毯下的彻底错误。
以这种方式规定思维，你正在建立真正强大的软件。
事件处理程序对我来说是.NET应用程序内存消耗的最大威胁，特别是如果您在Web服务器上下文中开始使用它。 对我来说，始终是附属于deattach的对象的责任。 附加对象应该始终具有与其附加的对象相比更小或相等的寿命，否则事件的设计会出现问题，因为您不希望被通知对象的更改，而这些更改没有任何意义。 如果它们的寿命相等，它们将一起超出范围而你不需要做任何事情，如果它比连接对象必须分离的更短。 在基本Web应用程序中，您只有3种类型的lifespans，应用程序，会话和页面，并且规则易于应用。 在更复杂的应用程序中，这需要更多的思考。