Czy trzeba „unwire” obsługi zdarzeń w ASP.NET WebForms

Question

Biorąc pod uwagę, że wszystkie kontrole w WebForm są zniszczone (przez mojego zrozumienia) na końcu każdego odświeżenie zrobić trzeba „unwire” żadnych obsługi zdarzeń mogą mieć okablowany? (Zakładając, że chcesz zatrzymać obsługi zdarzeń i pozwalają GC)

Tak na przykład:

public partial class WebForm1 : System.Web.UI.Page 
{ 
    protected void Page_Load(object sender, EventArgs e) 
    { 
     //Do I need to remove this handler? 
     btnSubmit.ServerClick += btnSubmit_ServerClick; 
    } 
} 

Answer 1

Mało prawdopodobne. Twój okres istnienia instancji WebForm1 kończy się tuż po zdarzeniu Unload, jeśli dobrze pamiętam. To nie jest tak, że po wyświetleniu strony i po zakończeniu czyszczenia istnieje ciągłe odwołanie do klasy WebForm1.

Answer 2

Nie, nie trzeba. Będą zebrane śmieci.

Answer 3

udało mi się złożyć aplikacji internetowych (Webform) raz z dynamicznych kontroli, musiałem „unwire” moje wydarzenia, w przeciwnym razie strona stała się coraz wolniej. "stare" strony, o których myślałem, że GC zadbał, były wciąż w pobliżu. Kiedy rozpakowałem wydarzenie w Page_Unload mojej aplikacji, nie było już gromadzone wydarzenie dla nieistniejących stron.

To zdarzyło mi się tylko raz, a było to prawdopodobnie spowodowane dynamicznym charakterem aplikacji.

Tylko do myślenia :)

Answer 4

To zbyt uproszczone założenie webform jest krótkotrwały - w tym przykładzie wyglądają dobrze, ale ogólnie należy być ostrożnym.

Właśnie dzisiaj, ja się na dobry przykład podobny do @thmsn gdzie brak unwire an obsługi zdarzeń w aplikacji ASP.NET WebForms było przyczyną paskudny wyciek pamięci.

W tym przypadku strona wzorcowa stosowane w prawie wszystkich stron było zapisanie się na razie w obiekcie To Page_Init. Obiekt, o którym mowa, był długotrwały i utrzymywał się w sesji ASP.NET, a strona została skonfigurowana do korzystania z magazynu sesji InProc z 60-minutowym limitem czasu. Nieodłączenie modułu obsługi zdarzeń spowodowało, że obiekt uniemożliwiał GC uzyskiwanie dostępu do wszystkich stronpodczas sesji tak długo, jak długo zachowywał (co najmniej przez godzinę w każdym przypadku).

Szybka korekta polegała na rozpinaniu programu obsługi zdarzeń w Page_Unload - ten przykład pokazuje, że okres istnienia strony można łatwo nieświadomie wydłużyć poza okres przydatności do użycia. Nie będę tu używał Sesji, chociaż daleko jej było do ideału - i widziałem podobne błędy z odsyłaczami wstecznymi z obiektów o odpowiednio dłuższym czasie życia.