Šajā rakstā tiek pieņemts, ka lasītājs ir iepazinies ar ievadrakstu par ASP.Net
Šis ir īss izklāsts latviešu valodā no MSDN izklāsta par ASP.Net koda modeli
ASP.Net koda modelis ir viens no pirmajiem soļiem pretim Longhorn paredzēto aplikāciju izstrādes tehnikai, kur aplikācijas izskats tiek nodalīts no koda, kas apstrādā notikumus. Tādējādi “layouts” un “eventi” ir koda ziņā divi dažādi faili, kuru saturs aplikācijas izpildes laikā tiek ar “maģiskās mērces” palīdzību saķibināts vienotā baitu plūsmā.
Būtībā tiek risināta problēma, kuras dēļ, piemēram PHP skriptu gadījumā radīti tādi “template dzinēji” kā Smarty, tikai šeit problēmas risinājums iešūts pašā dzinējā.
ASP.Net lapas pamatā vienmēr būs koda klase System.Web.UI.Page. Šajā klasē implementētas visas darbam pamatā nepieciešamās metodes (piemēram, RenderControl, Validate un citas), pieejamas datu kolekcijas un svarīgākie objekti, kas atbalsta HTTP ideoloģiju(piemēram Request, Response, ViewState), klase realizē pietiekami sarežģītu notikumu modeli (pieejami notikumi, piemēram Init, Load, PreRender, DataBinding un citi)
Sākot veidot jaunu ASP.Net lapu, jāveido klase, kas mantota no Page klases. Tas ir, ja vēlamies izveidot primitīvu webformu uz kuras varētu atrasties viens nerediģējama teksta klucītis, kods ir šāds:
Public Class MyPage
Inherits Web.UI.Page
Protected MyLabel As Web.UI.WebControls.Label
End Class
Failu, kas satur šādu klasi, iespējams kompilēt, lietojot parasto Visual Basic.net kompilatoru vbc.exe un rezultātā iegūt *.dll failu, ko dēvē par code-behind bibliotēku.
Viegli pamanīt, ka iepriekš minētajā kodā nav informācijas par to, kāds izskatīsies Label objekts. WebFormas vizualizācija tiek veidota kā atsevišķs fails, kura paplašinājums parasti ir *.aspx. Šāda faila pirmā rinda ir norāde interpretatoram, kur meklēt no kādas klases mantota dotā webforma:
< %@ Page Language="vb" AutoEventWireup="false" Inherits="MyApp.MyPage"%>
Mazliet īpatnēji šajā kontekstā šķiet izmantot terminu mantošana, jo šādi sanāk, ka teksta fails manto koda klasi, bet tā to dēvēt izvēlējušies tehnoloģijas arhitekti. Ir iespējams vienai koda klasei piekārtot vairākas izskata lapas, bet ne otrādi.
Webformas layout fails tiek veidots kā HTML un ASP iezīmju maisījums, lietojot speciālas birkas kontroļu ievietošanai. Mūsu piemērs izskatās šādi (atvainojiet par liekajām atstarpēm birku sākumā, ir nelielas problēmas ar manu publicēšanas sistēmu):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<body>
<form id="Form1" method="post" runat="server">
<asp:Label id="MyLabel" runat="server"></asp:Label>
</form>
</body>
</HTML>
Šeit svarīgi ir tas, ka asp:Label ID atribūts sakrīt ar MyPage koda klases atribūta nosaukumu. Šādā veidā webformas lietotāja interfeisa kontrole tiek piesaistīta kodam, kas ar to darbojas. Ja ASP.Net lapa tiek veidota ar MS Visual Studio .Net, formas kontroļu saderību ar klases atribūtiem tiek nodrošināta automātiski.
Kas tad notiek tālāk. Rezultātā esam ieguvuši divus atsevišķus failus – mypage.aspx, kur definēts lapas izskats un myapp.dll, kurā implementētas lapas loģika. Izveidojam Internet Information Server pieejamu direktoriju uz cietā diska, piemēram, c:\inetpub\wwwroot\myapp\. Direktorijā ievietojam tikai .aspx failu un izveidojam papildus apakšdirektoriju bin, kurā ievietojam .dll failu.
IIS konfigurācijā izveidojam jaunu aplikāciju direktorijai c:\inetpub\wwwroot\myapp\ (kā to izdarīt).
Šajā brīdī IIS zina, ka visi .aspx faili, kas atrodas šajā direktorijā, turpmāk jāapstrādā ar ASP.Net ISAPI filtru jeb interpretatoru, kas tiks ielādēts no C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll (Tā arī tā manis minētā *maģiskā mērce*).
Kad lietotājs pieslēdzas tīmekļa serverim un pieprasa mūsu izstrādāto lapu (http://localhost/myapp/mypage.aspx) , IIS process sevī ielādē (ja vēl nav ielādējis) aspnet_isapi.dll bibliotēku un tai palūdz procesēt lapu mypage.aspx. Interpretators noskaidro, ka mypage.aspx ir mantota no koda klases MyPage, kas atrodama bibliotēkā myapp.dll. Rezultātā IIS procesā tiek ielādēta arī myapp.dll bibliotēka’. Tālāk tiek izpildīts kods, kas galu galā atgriež rezultātu IIS procesam, kurš to nodod atpakaļ lietotājam.
Koda izpildes laikā lapa ‘izdzīvo’ savudzīves ciklu. Lai imitētu Windows formas darba stilu, tiek veiktas daudzas lietotājam nezināmas darbības, piemēram, lapā saliktas datu ievades kontroles, to vērtības atjaunotas uz sākotnējām vai tādām, uz kādām lietotājs tās pamainījis pirms kādas pogas nospiešanas, tiek apstrādāti notikumi kā “nospiesta poga A” vai “nomainījies izvēlētais ieraksts listboxī” un citi.
Skaists un pilnīgs lapas dzīves cikla apraksts atrodams 15Seconds rakstā, bet īsumā, kas notiek:
- Objektu un kontroļu inicializēšana
- ViewState datu atjaunošana (par šo stāstīšu nākamajā rakstā)
- PostBack datu apstrāde- tas, ko lietotājs ir pamainījis formā
- Tiek pacelti izmaiņu notikumi (onclick, onselectedindexchanged etc)
- Tiek ģenerēts HTML
- Tiek ģenerēts jaunais ViewState
Pēc tam lietotājs atkal kaut ko pamaina WebFormā, katra darbība pārsūta datus uz serveri, un atkal notiek šāda pat procedūra. Tādējādi jebkuras pogas nospiešana patiesībā pārsūta datus atkārtoti uz serveri, tur tiek apstrādāts šīs pogas onClick notikums un ģenerēts jauns, droši vien jau citāds HTML kods. Visu tekstu ievades lauku dati saglabājas, jo arī tie tiek pārsūtīti uz serveri, bet, atšķirībā no PHP aplikācijām, izstrādātājam ne obligāti būs jārūpējas par to, lai no POST (vai GET) datiem atjaunotu ievades lauka stāvokli – to izdarīs ASP.net.