views:

530

answers:

2

Do the same best practis rules regarding subscribing/unsubscribing to events apply in asp.net?

I know it might seem like a silly question, but when I think about it, I have never really seen any code where people first subscribe to an event on a page and then unsubscribe later on in the web request.

Example 1: On a page, in the Page_Load method, I subscribe to a updating event on a ListView. Should I unsubscribe from that event later on, for example in the OnPreRenderComplete method?

Example 2: In the passive view patter, a view (Page control/Usercontrol) will raise an event whenever it needs the presenter to do anything. So the presenter needs to subscribe to events on the view, but do it also need to unsubscribe from the events again?

Best regards, Egil.

+2  A: 

Generally, no. Events are supposed to be dumped automatically when the page unloads. SUPPOSED to be. I've run into a bug before (in .NET 1.1) where that wasn't the case.

I won't bother unsubscribing, unless I notice a problem with the page (like, a method being called 20 times from a phantom in the call stack: that's usually a sign of something not being unsubscribed properly).

DannySmurf
+2  A: 

The page instance and all of its components will "go out of scope" when request completes, e.g. they become eligible for GC. So your ListView will go out of scope along with the Page/user controls on it. You don't need to unsubscribe (unless you subscribe to an event that belongs to some kind of singleton that survives every request and use one of the methods of the page as the event handler, for example).

The same thing is valid for the presenter (again as long as this presenter is used solely with one page and goes out of scope after that).

liggett78
Ok, just to be sure I understand you correctly: if I have a singleton object in the asp.net cache, a presenter should not subscribe to an event on that, since the singleton will not be disposed when the page goes out of scope, and the presenter will thus hang around?
Egil Hansen
Yes, I've updated the wording in my answer. Basically you should not leave any references to the page (or any control in it) withing your long-living objects. An event handler could be such a reference.
liggett78
Just an example: if you subscribe to an event of a long-living object and use one of the methods of your page as a handler, then your long-living object holds a reference to the page. For the GC the page is still visible/in-scope. A static method as event handler would be OK though.
liggett78
And of course you can subscribe to any event, even on long-living objects, as long as you unwire the event after you're done. Just to be clear here :-)
liggett78
great, thanks for clearing that up for me.
Egil Hansen
I ran into the singleton event handler preventing GC issue in Winforms and was causing a nice memory leak with dialog boxes. The easy solution was to ensure I remove the handler when I try to close/dispose the dialog and all was well.
Chris Porter