Ana içeriğe atla

ASP.NET Sayfa Yaşam Döngüsü (Page Life Cycle)

Asp.NET’in sayfa yaşam döngüsünde istemcinin yaptığı her istekte page nesnesi ve içindeki kontroller yeniden oluşturulur. Bu da sayfanın ve kontrollerinin yaşam döngüsü aşamalarını ntekrarlaması anlamına gelir. HTPP runtime’ın ProcessRequest metodun çağırmasıyla sayfa ve kontrollerin yaşam döngüsü tetiklenir. Yaşam döngüsü bazıları geliştirici tarafından kontrol edilebilecek bazıları da geliştiricinin müdahale edemeyeceği public olmayan aşamalardan oluşur. Kısaca yaşam döngüsü üç ana aşamadan ve bunların alt aşamalarından oluşur. Bu aşamalar;
  • setup
  • postback
  • finalization
1. Setup
Aspx sayfasının kaynağındaki sınıfa bakılarak page nesnesi yaratılır. Kontrol ağacı yaratılarak sayfaya bağlanır. Sayfa üzerindeki kontroller, http context, request ve response nesneleri set edilir. Sayfanın neden işletildiği belirlenir (yeni bir istek, postback sonucu oluşan bir istek..). Ve Page nesnesi buna göre kendi içsel durumunu düzenler.
Preinit Event
IsPostBack, IsCallBack, IsCrossPagePostback propertylerinin değerleri bu aşamada okunabilir.Bütün kontroller bu aşamada yaratılmış ve default değerlerine set edilmiştir.  Eğer kontrollerin idsi aspx kaynağında belirtilmediyse, bu aşamada o kontrollerin bir idsi yoktur. Sayfanın scroll pozisyonu ve post edilmiş veriler bu aşamada elde edilebilirdir. MasterPage’i veya temayı değiştirmek sadece bu aşamada mümkündür.
Init  Event
Master Page ve tema artık değiştirilemez. PreInit aşamasında idleri olmayan kontrollere id atanır. Bütün kontrollerin OnInit event’i tetiklenerek kendi durumlarını ilklemeleri sağlanır. Bu aşamada viewstate henüz yüklenmemiştir.

InitCompleteEvent
İlkleme aşamasının bitiş eventidir. Bu iki aşama arasında view-statede yapılan değişikliklerin izlenmesi aktif hale getirilir. View-state’i takip edilen kontrollerde, kontrole programsal olarak eklenen herhangi bir değer viewstate koleksiyonuna da eklenir. Böylece bu değerler postback sırasında kaybolmaz.
ViewState’i Yükleme
Sayfa bir postback isteği sonucunda işletiliyorsa, __VIEWSTATE gizli sahasından bütün kontrollerin sayfanın tarayıcıya en son gönderildiğindeki durumları alınarak yüklenir.  Böylece son istekle şu anki durum eşitlenmiş olur. ASP.NET, sayfadan gelen ViewState'in içeriğindeki veriyi almak için LoadViewState metodunu kullanır. Bu metod override edilebilir bir metodtur.
Posted Data’yı İşleme
HTTP Request ile birlikte gelmiş Postback data okunur ve ilgili kontrollere yüklenir. <form> tagi ile belirtilmiş gizli sahalar bu aşamada işlenir. Bir server kontrolü IPostBackDataHandler arayüzünü implemente ederek posted data ile ilgilendiğini belirtir. Page sınıfı gönderilen posted datadaki ilgili kontrolü bulur ve kontrolün IpostBackDataHandler arayüzünü implemente edip etmediğine bakar. Eğer kontrol bu arayüzü implemente ediyorsa, kontrolün durumunu güncellemek üzere interfacedeki LoadPostData methodu çağırılır.
PreLoad Event
Bu event sayfanın ilkleme aşamasından çıktığını ve kullanıcı kodunun sayfanın işletimini yapılandırabileceği aşamaya geçtiğini gösterir.
Load Event
Load event’i önce sayfa daha sonra ise sayfanın bütün kontrolleri için çağırılır. Bu aşamada sayfadaki bütün kontroller yaratılmıştır. Kontroller bir önceki durumları ve post edilmiş veriler güncellenmiştir. Kontroller ve viewstate artık kararlı bir duruma gelmiştir.
PostBack’i Yönetme
Sayfa ilklemesinden ve posted veriler işlendikten sonra postback işlemlerini yaratan eventler tetiklenir. Başlıca iki tip event gerçekleşir. Bunlardan ilki belirli kontrollerin durumunun değiştiğini gösterir. Bir textbox’ın TextChanged eventinin tetiklenmesi buna bir örnek olarak verilebilir. Bu aşamada IPostBackDataHandler arayüzünün RaisePostDataChangedEvent metodu çağırılır. Bu durum kontrolün ASP.Net uygulamasına durumunun değiştiğini bildirebilmesini sağlar. Bu metodun implementasyonu kontrola bırakılmıştır.
Diğeri ise istemcinin yaptığı işlem ile oluşan postback sonucunda işletilen eventlerdir.  Örneğin bir buton tıklandığı zaman işlemci butonun IPostBackDataHandler RaisePostDataChangedEvent  metodunu çağırır. Her kontrol implementasyonunu kendi yapar ve kontrolden kontrole değişiklik gösterebilir. Örneğin Buton ise kullanıcının postback işlemiyle ilgili kodu yazabileceği OnClick gibi bir eventi tetikler.
LoadComplete Event
LoadComplete eventi sayfanın hazırlanma aşamasının bittiğini gösterir. Sayfadaki hiçbir child control bu eventi almaz. Bu aşamadan sonra sayfa rendering aşamasına girer.
2. Finalization
Bu aşamada, sayfa tarayıcı için bir markup üretmeye hazır duruma gelmiştir. Bu aşamayı pre-rendering ve markup üretimi olmak üzere iki basamakta inceleyebiliriz.

PreRender
Event
Sayfa  ve kontroller için bir çıktı üretilmeden ve Viewstate kaydedilmeden önce yapılacak değişiklikler bu aşamada yapılır. Bu event önce sayfada daha sonra ise bütün çocuk kontrollerde çağırılır.
PreRenderComplete Event
Pre-render aşamsında sayfanın bütün kontrollerinde tekrarlı olarak çağırıldığı için, geliştiricinin pre-render aşamasının tamamlandığını bilmesinin imkanı yoktur. Bunun için sadece sayfaya özel bu event çağırılır.
SaveStateComplete Event
Her kontrol markup’ının üretilmesi için render olmadan önce kontrollerin ve sayfanın o anki durumu sunucuya yapılacak bir sonraki istekte hatırlanabilmesi için Viewstate nesnesine kayıt edilir. Bu aşamadan sonra yapılacak olan her değişiklik render işlemini etkileyecektir. Fakat viewstate nesnesine kaydedilmediği için bir sonraki postbackte kalıcı olmayacaktır. ViewState’i kaydetme işlemi her kotrolün ve sayfanın SaveViewState metodu çağırılarak  yürütülen yinelemeli bir işlemdir.
Markup Oluşturulması
Browser için markup’ın üretilmesi aşaması, her bir kontrol kendi markup’ını render etmesi ile işlemini içerir. Bazı overridable metodlar geliştiricinin markup üretimine müdahalede bulunabilmesine olanak sağlar.
Unload Event
Render aşamasından sonra önce kontrollerin unload eventi daha sonra da sayfanın unload eventi tetiklenerek son  temizlik işlemlerinin yapılır. Bu metod açık kalmış dosya ve database bağlantıları kapatmak gibi işlemler için kullanılabilir.
image
Şekil1. ASP.NET Page Lifecycle
Referanslar
Özlem KARAGEDİK

Yorumlar

  1. Tebrik Ederim Sizi. Kısa ama açıklamalı bir anlatım olmuş

    YanıtlaSil

Yorum Gönder

Bu blogdaki popüler yayınlar

UML ve Modelleme – Bölüm 4 (Class (Sınıf) Diyagramları)

Bir önceki makalemizde UML modellemede kullanılan ilk diyagram olan Use Case diyagramını incelemiştik. Bu makalemizde nesne tabanlı programlamada kullanılan sınıflar ve sınıfların arasındaki ilişkileri modelleyebileceğimiz diyagramlar olan Class(Sınıf) diyagramlarını inceleyeceğiz. UML’de sınıflar, nesne tabanlı programlama mantığı ile tasarlanmıştır. Sınıf diyagramının amacı bir model içerisinde sınıfların tasvir edilmesidir. Nesne tabanlı uygulamada, sınıfların kendi özellikleri (üye değişkenler), işlevleri (üye fonksiyonlar) ve diğer sınıflarla ilişkileri bulunmaktadır. UML’de sınıf diyagramlarının genel gösterimi aşağıdaki gibidir. Şekil 1. Class Diyagram Şekil1’de görüldüğü üzere bir dikdörtgeni 3 parçaya bölüyoruz. En üst bölüm sınıf adını, orta kısım özellik listesini (üye değişkenler) ve en son kısım, işlev listesini (üye fonksiyonlar) göstermektedir. Çoğu diyagramlarda alt iki bölüm çıkarılır. Genelde tüm özellik ve işlevler gösterilmemektedir. Ama

Yazılım Maliyet Tahmineleme Tecrübeleri

Yazılım mühendisliğinde maliyet hesabı her zaman problem olmuştur. "Bu iş kaç Adam/Gün tutar?" sorusuyla sıkça karşılaşıyoruz. Adam/gün veya Adam/ay ölçütleri bir kaynağın/kişinin belirtilen zaman dilimindeki iş gücü anlamına gelir. Tabi bu noktada yine kafa karışıklıkları başlar. 6 A/G'lik bir işi hızlandıralım diye 2 kişi ile yapmaya çalışsak ve kaynak/kod, modül, altyapı, insan vb. her bir şeyi bir kenara bıraksak, matematiksel basit formülle 6/2=3 A/G'de biter? Gerçek hayat böyle değil, öncelikle bunu anlamamız lazım. Hep şu örnek verilir; "Aynı bebeği 2 kadın birlikte daha kısa sürede doğurur mu?" Eğer bunun cevabı "Evet" ise (veya bir gün böyle bir durum ortaya çıkarsa), yazımı değiştirmem gerekecek:) Mevzu gerçekten derin...Maliyet hesabı; bulunduğunuz firmanın yazılım süreçlerini hangi methodlarla uyguladığına, ilgili işin o dönemdeki aciliyetine, (şirket yönetiminin baskısına:)) vb. bir çok duruma bağlı olabilir. Örneğin; bizim firmada e

UML ve Modelleme – Bölüm 3 (Use Case Diyagramlar)

Önceki iki makalemizde ( 1 , 2 ) UML’e genel olarak değinip ve modellemede kullanacağımız dokuz diyagram hakkında bilgiler vermiştik. Bu makalemizde Use Case diyagramından detaylı bahsedeceğiz. Öncelikle, genel Use case diyagramının tanımını hatırlayalım. “Bir kullanıcı ve bir sistem arasındaki etkileşimi anlatan senaryo topluluğudur.” Ivar Jacobson Senaryo tanımı için der ki: “Aktörle sistem arasında gerçekleştirilen, sonucunda aktöre farkedilir getirisi/ faydası oluşan etkileşimli diyalogdur. ” UML Use Case Diyagramları  sistemin işlevselliğini açıklamak amacıyla kullanılır. Sistemin birbirinden ayrı özelliklerinin detaylarını göstermekten ziyade, Use Case Diyagramlar, tüm mevcut işlevselliği göstermek için kullanılabilir. Buradaki en önemli noktalardan biri,   Use Case Diyagramlar temelde sequence diyagram ve akış diyagramlarından farklıdır. Use Case diyagramlar dört ana elemandan oluşmaktadır. Aktörler , Sistem (Proje kapsamını belirtir) , Use Caseler ve bunlar ara