Diskusi mendalam aplikasi Halaman Web ASP.NET

1. Pengenalan dasar skrip server

Pertama, mari kita tinjau metode eksekusi dasar halaman server Web:

1. Klien mengirimkan permintaan ke server dengan mengetikkan alamat di bilah alamat browser

2. Setelah server menerima permintaan, itu mengirimkannya ke Halaman sisi server yang sesuai (yaitu, skrip) dijalankan. Skrip menghasilkan respons dari klien dan mengirimkannya kembali ke klien.

3. Browser klien menerima respons dari server, mem-parsingnya Html, dan menyajikan halaman web grafis kepada pengguna. Untuk

interaksi antara server dan klien, metode utama berikut biasanya digunakan:

1. Formulir: Ini adalah metode yang paling penting. Kontrol standar digunakan untuk mendapatkan masukan pengguna. Pengajuan Formulir mengirimkan data ke server untuk diproses.

QueryString

: Dengan menambahkan parameter setelah Url, parameter dikirimkan ke server. Metode ini sebenarnya sama dengan metode Get

metode khusus, biasanya digunakan untuk mengonfirmasi identitas pengguna

. 2. ASP.Net Pendahuluan

Bahasa skrip server tradisional, seperti ASP, JSP, dll., menulis skrip server dengan cara yang hampir sama. Semuanya menyematkan kode yang ditafsirkan atau dikompilasi dan dieksekusi dalam Html, dan platform server mengeksekusi kode-kode ini untuk menghasilkan Html; untuk skrip serupa, halaman Siklus hidup Servlet sebenarnya sangat sederhana, yaitu semua kode dieksekusi dari awal hingga akhir Java dapat menulis kode yang lebih kompleks, tetapi dari sudut pandang struktural, tidak ada bedanya dengan JSP.

Kemunculan ASP.Net mematahkan tradisi ini; ASP.Net mengadopsi teknologi CodeBehind dan kontrol sisi server, menambahkan konsep kejadian sisi server, mengubah model penulisan bahasa scripting, dan menjadi lebih dekat dengan pemrograman Window, membuat pemrograman Web lebih mudah. , intuitif; tetapi kita harus melihat bahwa ASP.Net sendiri tidak mengubah model dasar pemrograman Web, ia hanya merangkum beberapa detail dan menyediakan beberapa fungsi yang mudah digunakan, membuat kode lebih mudah untuk ditulis dan dipelihara; sejauh ini, mempersulit cara eksekusi sisi server. Ini adalah topik utama yang akan kita bahas hari ini: siklus hidup Halaman Web ASP.Net.

3. Mode pemrosesan permintaan ASP.Net

Kami mengatakan bahwa Halaman Web ASP.Net tidak melepaskan diri dari mode pemrograman Web, sehingga masih bekerja dalam mode permintaan->menerima permintaan->memproses permintaan->mengirim respons dengan klien akan memicu permintaan baru, sehingga siklus hidup Halaman Web didasarkan pada satu permintaan.

Ketika IIS menerima permintaan dari klien, ia akan menyerahkan permintaan tersebut ke proses aspnet_wp untuk diproses. Proses ini akan memeriksa apakah domain aplikasi yang diminta ada. Jika tidak ada, ia akan membuatnya, dan kemudian membuat runtime Http ( HttpRuntime ) untuk menangani permintaan, runtime ini "menyediakan serangkaian layanan runtime ASP.NET untuk aplikasi saat ini" (dari MSDN).

Ketika HttpRuntime memproses permintaan, ia akan memelihara serangkaian contoh aplikasi, yaitu contoh kelas Global aplikasi (global.asax). Contoh ini akan disimpan dalam kumpulan aplikasi ketika tidak ada permintaan (sebenarnya Kumpulan aplikasi dipertahankan oleh kelas lain, HttpRuntime hanyalah panggilan sederhana). Setiap kali permintaan diterima, HttpRuntime akan mendapatkan instance yang menganggur untuk memproses permintaan tersebut kembali ke kumpulan, "Sebuah instance digunakan untuk menangani banyak permintaan selama masa pakainya, namun hanya dapat menangani satu permintaan dalam satu waktu." (Dikutip dari MSDN)

Ketika instance aplikasi menangani permintaan tersebut, ia akan Membuat sebuah instance kelas halaman permintaan dan jalankan metode ProcessRequest untuk memproses permintaan. Metode ini adalah awal dari siklus hidup Halaman Web.

4. Halaman Aspx dan CodeBehind

Sebelum kita mendalami siklus hidup halaman, mari kita bahas dulu beberapa hubungan antara Aspx dan CodeBehind.

<%@ Page Language="c#" Codebehind="WebForm.aspx.cs" Inherits="MyNamespace.WebForm" %>

Saya yakin teman-teman yang pernah menggunakan teknologi CodeBehind pasti sudah familiar dengan kalimat di bagian atas ASPX ini Analisa satu per satu:

Halaman bahasa = "c#" Tak perlu dikatakan lagi,

Codebehind = "WebForm.aspx.cs" Kalimat ini menunjukkan file kode terikat

Inherits = "MyNamespace.WebForm" Kalimat ini sangat penting. Ini mewakili nama kelas diwarisi oleh halaman, yang merupakan kelas dalam file kode CodeBehind. Kelas ini harus diturunkan dari System.Web.WebControls.Page.

Dari penjelasan di atas kita dapat menganalisis bahwa sebenarnya kelas di CodeBehind adalah basis halaman (ASPX). Pada titik ini, beberapa teman mungkin ingin bertanya. Saat menulis ASPX, Anda menyematkan kode atau kontrol server di Html persis sesuai dengan metode ASP. ?

Masalah ini sebenarnya tidak rumit. Teman-teman yang menggunakan pemrograman ASP.Net dapat masuk ke disk sistem Anda: WINDOWSMicrosoft.NETFramework<nomor versi>File ASP.NET Sementara, dan letakkan di bawah Semua file sementara ASP. Aplikasi .Net yang ada di mesin ini. Nama subdirektori adalah nama aplikasi, dan kemudian turun dua tingkat (untuk memastikan keunikan, ASP.Net secara otomatis menghasilkan dua tingkat subdirektori, dan subdirektori Namanya adalah acak), dan kemudian kita akan menemukan bahwa ada banyak pustaka tautan yang mirip dengan: "yfy1gjhc.dll", "xeunj5u3.dll" dan sumber seperti file "komee-bp.0.cs" dan "9falckav.0.cs" , sebenarnya, ini adalah hasil dari ASPX yang dikompilasi secara dinamis oleh ASP.Net. Saat kita membuka file sumber ini, kita dapat menemukan:

public

class WebForm_aspx: MyNamespace.WebForm, System.Web.SessionState.IRequiresSessionState

, ASPX Ini adalah subkelas dari kelas pengikatan kode. Namanya adalah nama file ASPX ditambah akhiran "_aspx". Dengan mempelajari kode-kode ini, kita dapat menemukan bahwa sebenarnya semua kontrol server yang ditentukan dalam aspx dihasilkan dalam kode-kode ini, dan kemudian Ketika kode-kode ini dihasilkan secara dinamis, kode yang awalnya tertanam di ASPX ditulis di lokasi yang sesuai.

Ketika suatu halaman dikunjungi untuk pertama kalinya, runtime HTTP akan menggunakan generator kode untuk mengurai file ASPX dan menghasilkan kode sumber dan mengkompilasinya. Kemudian kunjungan berikutnya akan langsung memanggil dll yang dikompilasi. Inilah mengapa ASPX Alasan mengapa akses tersebut sangat lambat.

Setelah menjelaskan masalah ini, mari kita lihat masalah lainnya. Saat kita menggunakan pengikatan kode, seret kontrol pada halaman desain, lalu alihkan ke tampilan kode, Anda dapat menggunakan kontrol secara langsung di Page_Load. Karena kontrol dibuat di subkelas, mengapa dapat digunakan di kelas induk? Bagaimana dengan menggunakannya secara langsung?

Faktanya, kita dapat menemukan bahwa setiap kali kita menggunakan VS.Net untuk menyeret kontrol ke halaman, pernyataan seperti ini selalu ditambahkan ke file pengikatan kode:

protected System.Web.WebControls.Button Button1

; bidangnya adalah Deklarasikan sebagai dilindungi, dan namanya konsisten dengan ID kontrol di ASPX. Jika Anda memikirkannya dengan cermat, masalah ini akan terpecahkan. Kami telah menyebutkan sebelumnya bahwa kode sumber ASPX dibuat dan dikompilasi secara dinamis oleh generator. Generator akan menghasilkan kode untuk secara dinamis menghasilkan setiap kontrol server. Saat membuat, ia akan memeriksa apakah kelas induk telah mendeklarasikan kontrol ini. itu akan menambahkan kode yang mirip dengan berikut:

this.DataGrid1 = __ctrl;

__ctrl ini adalah variabel yang menghasilkan kontrol. Saat ini, ia menetapkan referensi kontrol ke variabel yang sesuai di kelas induk, itulah sebabnya kelas induk Deklarasi tersebut harus dilindungi (sebenarnya bisa juga bersifat publik), karena perlu dipastikan bahwa subkelas dapat memanggilnya.

Kemudian ketika Page_Load dijalankan, karena deklarasi kelas induk telah diberi nilai oleh kode inisialisasi di subkelas, kita dapat menggunakan bidang ini untuk mengakses kontrol yang sesuai. Mengetahui hal ini, kita tidak akan melakukan pengikatan kode menggunakan kontrol tersebut di konstruktor dalam file yang ditentukan menyebabkan kesalahan pengecualian referensi nol. Karena konstruktor dijalankan terlebih dahulu, inisialisasi subkelas belum dimulai, sehingga bidang di kelas induk memiliki nilai nol. Adapun subkelasnya Akan kita bahas nanti ketika sebuah kelas diinisialisasi.

5. Siklus Hidup Halaman

Sekarang kembali ke konten yang disebutkan dalam judul ketiga, kita berbicara tentang contoh HttpApplication menerima permintaan dan membuat sebuah instance dari kelas halaman. Faktanya, instance ini adalah sebuah instance dari kelas ASPX yang dikompilasi secara dinamis. Pada judul sebelumnya kita mengetahui bahwa ASPX sebenarnya adalah subkelas dari kelas yang terikat kode, sehingga mewarisi semua metode yang dilindungi.

Sekarang mari kita lihat kode kelas CodeBehind yang secara otomatis dihasilkan oleh VS.Net untuk memulai diskusi kita tentang siklus hidup halaman:

#region Web Form Designer menghasilkan kode

override protected void OnInit(EventArgs e)
{
//
// CODEGEN: Panggilan ini diperlukan oleh perancang Formulir Web ASP.NET.
//
Inisialisasi Komponen();
base.OnInit(e);
}

/// <ringkasan>
/// Desainer mendukung metode yang diperlukan - jangan gunakan editor kode untuk memodifikasi
/// Isi dari metode ini.
/// </ringkasan>

kekosongan pribadi InitializeComponent()
{
this.DataGrid1.ItemDataBound += Sistem.Web.UI.WebControls.DataGridItemEventHandler baru(ini.DataGrid1_ItemDataBound);

ini.Muat += Sistem.EventHandler(ini.Page_Load);
}

#endregion

Ini adalah kode untuk Halaman yang dibuat menggunakan VS.Net. Mari kita lihat. Ada dua metode di dalamnya, satu adalah OnInit dan yang lainnya adalah InitializeComponent awal inisialisasi halaman. Di InitializeComponent kita melihat deklarasi event dari kontrol dan deklarasi Load dari Halaman.

Berikut ini adalah deskripsi yang dikutip dari MSDN dan tabel urutan metode siklus hidup halaman dan pemicu peristiwa:

"Setiap kali halaman ASP.NET diminta, server memuat halaman ASP.NET dan membongkar halaman ketika permintaan selesai. Kontrol halaman dan server di dalamnya bertanggung jawab untuk melaksanakan permintaan dan merender HTML ke klien. Meskipun komunikasi antara klien dan server tidak memiliki kewarganegaraan dan terputus-putus, hal itu harus dianggap oleh klien sebagai proses yang berkelanjutan.

"Ilusi kontinuitas ini diterapkan oleh kerangka halaman ASP.NET, halaman, dan kontrolnya. Setelah postback, perilaku kontrol harus muncul mulai dari tempat permintaan Web terakhir berakhir. Kerangka kerja dapat membuat manajemen status eksekusi menjadi relatif mudah, tetapi untuk mencapai efek kontinuitas, pengembang kontrol harus mengetahui urutan eksekusi kontrol. Pengembang kontrol perlu memahami informasi apa yang dapat digunakan dan data apa yang dapat disimpan oleh kontrol pada setiap tahap siklus hidup kontrol keadaan di mana kontrol dirender. Misalnya, kontrol tidak dapat memanggil induknya hingga pohon kontrol pada halaman diisi." Tabel berikut memberikan ikhtisar tingkat tinggi mengenai tahapan dalam siklus hidup kontrol. Klik di tabel. link."

Dari tabel ini, kita dapat melihat dengan jelas metode yang dipanggil dan waktu pemicuan suatu Halaman dari memuat hingga membongkar.

Setelah melihat tabel di atas, teman-teman yang penuh perhatian mungkin bertanya, karena OnInit adalah awal dari siklus hidup halaman, dan kita telah membicarakan tentang kontrol yang dibuat di subkelas pada kuliah sebelumnya, di sini kita sebenarnya menggunakan metode InitializeComponent Bidang yang dideklarasikan di kelas induk sudah bisa digunakan, jadi apakah subkelasnya sudah diinisialisasi sebelum ini?

Pada judul ketiga, kami menyebutkan bahwa ProcessRequest dari kelas halaman adalah awal dari siklus deklarasi halaman dalam arti sebenarnya. Metode ini disebut dengan HttpApplication (metode pemanggilannya lebih rumit, dan saya akan memiliki kesempatan untuk menulis a. artikel terpisah untuk menjelaskannya). Halaman Pemrosesan permintaan dimulai dari metode ini. Dengan mendekompilasi perpustakaan kelas .Net untuk melihat kode sumber, kami menemukan kelas dasar System.Web.WebControls.Page: System.Web. WebControls.TemplateControl (ini adalah halaman dan kontrol pengguna Metode virtual "FrameworkInitialize" didefinisikan di kelas dasar), dan kemudian metode ini pertama kali dipanggil di ProcessRequest Halaman. Kami menemukan jejak metode ini di kode sumber ASPX dihasilkan oleh generator. Semua kontrol ada di Inisialisasi dalam metode ini, dan pohon kontrol halaman dibuat saat ini.

Hal berikutnya yang sederhana, mari kita analisis secara bertahap setiap item siklus hidup halaman:

1.

Inisialisasi Inisialisasi berkaitan dengan peristiwa Init dan metode OnInit pada Halaman.

Jika Anda ingin menulis ulang, MSDN merekomendasikan untuk membebani metode OnInti secara berlebihan daripada menambahkan proxy untuk acara Init. Ada perbedaan antara keduanya. Yang pertama dapat mengontrol urutan pemanggilan metode OnInit dari kelas induk, sedangkan yang terakhir hanya dapat digunakan di kelas induk. Dieksekusi setelah OnInit (sebenarnya disebut di OnInit).

2. Memuat status tampilan

Ini adalah metode yang lebih penting. Kita tahu bahwa setiap permintaan sebenarnya diproses oleh instance kelas halaman yang berbeda. Untuk memastikan status antara dua permintaan, ASP.Net menggunakan ViewState.

Metode LoadViewState memperoleh status terakhir dari ViewState, dan menggunakan rekursi untuk melintasi seluruh pohon sesuai dengan struktur pohon kontrol pada halaman untuk memulihkan status terkait ke setiap kontrol.

3. Memproses data postback

Metode ini digunakan untuk memeriksa apakah status data kontrol yang dikirim kembali oleh klien telah berubah. Prototipe metode:

public virtual bool LoadPostData(string postDataKey, NameValueCollection postCollection)

postDataKey adalah kata kunci yang mengidentifikasi kontrol (yaitu, Kunci di postCollection). postCollection adalah kumpulan yang berisi data postback pengembalian Apakah data yang dikirim telah berubah, jika demikian, ia mengembalikan Benar, "LoadPostData mengembalikan nilai benar jika status kontrol berubah karena postback; jika tidak maka akan mengembalikan salah. Kerangka halaman melacak semua kontrol yang mengembalikan nilai benar dan memanggil RaisePostDataChangedEvent pada kontrol ini . "(Dikutip dari MSDN)

Metode ini didefinisikan di System.Web.WebControls.Control, dan juga merupakan metode yang harus ditangani oleh semua kontrol khusus yang perlu menangani peristiwa. Untuk Halaman yang kita bahas hari ini, Anda dapat membiarkannya. sendiri.

4. Loading

berhubungan dengan event Load dan metode OnLoad. Saya yakin sebagian besar teman-teman pasti sudah familiar dengan event ini. Metode Page_Load di halaman yang dihasilkan oleh VS.Net adalah metode untuk merespon event Load acara akan dipicu. , metode Page_Load juga akan dijalankan. Saya yakin ini juga merupakan langkah pertama bagi kebanyakan orang untuk memahami ASP.Net.

Metode Page_Load merespons peristiwa Load, yang didefinisikan di kelas System.Web.WebControl.Control (kelas ini adalah nenek moyang Page dan semua kontrol server) dan dipicu dalam metode OnLoad.

Mungkin banyak orang yang mengalami hal seperti itu. Mereka menulis kelas PageBase dan kemudian memverifikasi informasi pengguna di Page_Load. Ternyata verifikasi berhasil atau tidak, Page_Load halaman subkelas akan selalu dieksekusi terlebih dahulu kali ini, beberapa informasi mungkin tertinggal. Sebagai risiko keamanan, pengguna dapat menjalankan metode Page_Load di subkelas tanpa diautentikasi.

Alasan untuk masalah ini sangat sederhana, karena metode Page_Load ditambahkan ke event Load di OnInit, dan metode OnInit dari subkelas terlebih dahulu menambahkan event Load dan kemudian memanggil base.OnInit, yang menyebabkan subkelas Page_Load ditambahkan terlebih dahulu , lalu dieksekusi terlebih dahulu.

Mengatasi masalah ini juga sangat sederhana. Ada dua metode:

1) Overload metode OnLoad di PageBase, lalu autentikasi pengguna di OnLoad, lalu panggil base.OnLoad, karena event Load dipicu di OnLoad, jadi kita bisa pastikan Otentikasi pengguna sebelum mengaktifkan acara Load.

2) Panggilan pertama base.OnInit dalam metode OnInit subkelas untuk memastikan bahwa kelas induk mengeksekusi Page_Load terlebih dahulu.

5. Kirim pemberitahuan perubahan postback.

Metode ini sesuai dengan pemrosesan data postback pada langkah 3. Jika data postback diproses , True dikembalikan. Kerangka halaman akan memanggil metode ini untuk memicu peristiwa perubahan data, sehingga peristiwa perubahan data postback dari kontrol kustom perlu dipicu dalam metode ini.

Demikian pula, metode ini tidak terlalu berguna untuk Page. Tentu saja, Anda juga dapat menentukan peristiwa perubahan data berdasarkan Page.

6. Menangani peristiwa postback

Metode ini adalah tempat sebagian besar peristiwa kontrol server dipicu. Ketika permintaan berisi informasi tentang pemicu peristiwa kontrol (peristiwa kontrol server adalah topik lain, saya akan menulis artikel lain untuk dibahas dalam waktu dekat), kontrol halaman Metode RaisePostBackEvent dari kontrol terkait akan dipanggil untuk memicu kejadian sisi server.

Inilah pertanyaan umum lainnya:

Netizen sering bertanya mengapa data yang dikirimkan tidak berubah setelah modifikasi.

Dalam kebanyakan kasus, mereka tidak memahami proses pemicuan peristiwa server. Kita dapat melihat bahwa peristiwa server dipicu setelah Pemuatan Halaman. , artinya halaman akan mengeksekusi Page_Load terlebih dahulu, lalu mengeksekusi event klik tombol (ini contoh tombolnya). Banyak teman yang mengikat data di Page_Load, lalu memproses perubahan di event tombol tersebut ada masalah dengan ini, Page_Load selalu dijalankan sebelum peristiwa tombol, yang berarti bahwa sebelum data sempat berubah, kode pengikatan data di Page_Load dijalankan terlebih dahulu, dan data asli ditugaskan ke kontrol, kemudian ketika event button dijalankan, yang sebenarnya didapat adalah data asli, jadi update tentunya tidak akan berpengaruh.

Mengubah masalah ini juga sangat mudah. ​​Pendekatan yang lebih masuk akal adalah dengan menulis kode pengikatan data ke dalam suatu metode, anggap saja itu adalah BindData:

private void BindData()
{
//Mengikat data
}

Kemudian ubah PageLoad:

private void Page_Load( pengirim objek,EventArgs e)
{
jika(!IsPostBack)
{
BindData(); //Ikat data saat halaman diakses pertama kali}
}

Akhirnya di acara tombol:

private Button1_Click( pengirim objek,EventArgs e )
{
//Perbarui dataBindData();//Ikat ulang data
}

7.

Pemrosesan permintaan akhir untuk pra-render akan diubah menjadi respons yang dikirim kembali ke server. Tahap pra-render adalah melakukan perubahan status yang dilakukan sebelum rendering akhir, karena sebelum merender suatu kontrol, kita harus menghasilkan Html berdasarkan propertinya, seperti atribut Style, yang merupakan contoh paling umum. Sebelum melakukan pra-render, kita dapat mengubah Gaya suatu kontrol. Saat pra-render dilakukan, kita dapat menyimpan Gaya dan menampilkan Html informasi gaya sebagai tahap rendering.

8. Simpan status.

Tahap ini untuk status pemuatan. Kami telah menyebutkan berkali-kali bahwa berbagai instance sedang diproses di antara permintaan, jadi kami perlu menyimpan status halaman ini dan mengontrolnya .

9. Pada

titik ini, pemrosesan permintaan halaman pada dasarnya telah berakhir. Dalam metode Render, pohon kontrol seluruh halaman akan diulang, metode Render akan dipanggil secara berurutan, dan kode Html yang sesuai akan ditulis. ke dalam aliran respons akhir.

10. Pembuangan

sebenarnya adalah metode Buang. Pada tahap ini, sumber daya yang ditempati, seperti koneksi database, akan dilepaskan.

11.

Di akhir pembongkaran, halaman akan menjalankan metode OnUnLoad untuk memicu event UnLoad, yang menangani pemrosesan akhir sebelum objek halaman dimusnahkan. Faktanya, ASP.Net menyediakan event ini hanya untuk pertimbangan desain sumber daya selesai dalam metode Buang. Jadi metode ini menjadi tidak berguna.

Kami secara singkat memperkenalkan siklus hidup halaman, dan memberikan penjelasan yang kurang mendalam tentang pemrosesan peristiwa di sisi server. Hari ini saya terutama ingin semua orang memahami siklus eksekusi halaman. Saya akan menulis lebih banyak tentang peristiwa dan masa pakai kontrol server di artikel mendatang untuk dibahas.

Isi ini adalah beberapa pengalaman saya dalam penelitian Halaman ketika saya belajar ASP.Net. Detail spesifiknya tidak dibahas secara rinci. Silakan merujuk ke MSDN untuk informasi lebih lanjut, tetapi saya telah mengutip beberapa kesalahan umum dan kesalahan yang dilakukan oleh pemula , semoga dapat memberikan inspirasi bagi semuanya.