Tales from under the Mountain

MVC framework i sva njegova lica

Na prošlom sastanaku (januarskom) user grupe, prezentova sam jedan deo novog ASP.NET 3.5 Extensions paketa, ASP.NET MVC Framework. Primetio sam da postoje neka pitanja koja su malo opštija od prostih tehničkih činjenica, a na koja nisam stigao da odgovorim jer nismo imali toliko vremena. Jedan blog post bi trebalo sve to da razreši.

Prvo malo osnovnih stvari

Za one koji nisu bili na januarskom sastanku, ili su možda zaboravili o čem use ovde radi, malo podsećanje.

MVC je akronim za Model-View-Controller obrazac (design pattern), koji je svoju kreaciju video još dalekih '70-ih godina u Smalltalk-u. Osnovna odlika ovog obrasca jeste da predstavlja razdvajanje domena u tri jasno razdvojena sloja:

1. Model, koji služi za prikaz i rad sa podacima, odnosno predstavlja podatke koje koristite u aplikaciji putem objekata.
2. View, koji služi za predstavljanje informacija krajnjem korisniku.
3. Kontroler, glavna komponenta predstavlja sponu između modela i view-a i sadrži svu aplikativnu logiku.

Ove tri komponente zajedno imaju . Osnovna razlika između standardnog ASP.NET-a i MVC Framework-a je u tome što zahteve klijenata ne opslužuju strane, već kontrolerli. Drugim rečima, kada klijent uputi zahtev ka web serveru, IIS ne rutira taj zahtev do aspx strane, već do kontrolera. U URL-u kojim klijent zahteva od servera se nalazi nekoliko sučtinskih podataka, kao što je ime kontrolera, ime akcije na kontroleru i parametri koji se prenose. Donji dijagram ilustruje kako ova interakcija izgleda.

Dakle, na osnovu gornjeg dijagrama, rečima iskazana interakcija se dešava na sledeći način:

1. Do kontrolera stiže zahtev, u kome se nalazi informacija koju akciju sa kojim (eventualnim) parametrima je potrebno pozvati. Ukoliko ne postoji podatak o akciji, po default-u se koristi Index akcija.
2. Kontroler učitava model, ukoliko je potrebno.
3. Kontroler učitava view, prosleđuje mu podatke ukoliko je potrebno.
4. Odgovor, odnosno parsiran view, se vraća korisniku.

Primera radi, kontroler izgleda ovako:

Dok je view obična aspx strana sa kodom koji se i inače nalazi u običnoj aspx strani:

Ovakav rad sa resursima na serveru ima za posledicu nekoliko ključnih razlika između rada sa ovim framework-om i ASP.NET-om. Prvo, ne koristi se postback mehanizam u radu sa stranama. To sa sobom vuče još nekoliko stvari, kao što je recimo da ne postoji ViewState kontrola koje se (eventualno) koriste u view-ovima. Takođe, stranice nisu više ograničene na jedan formular po strani, već ih može imati koliko god se želi. Kada se radi o prenošenju podataka od klijenta ka serveru, u slučaju kada se ti podaci koriste za izmenu podataka u bazi, recimo, ne radi se događajima na strani (kao što je recimo Page_Load), a čuveni IsPostback gubi smisao. U ovom slučaju, u formularu za unos podataka se prosto kao paramtera action atributa odredi akcija na koju bi taj formuar trebalo da se postuje, i onda se u toj akciji radi sa podacima kroz Request kolekciju.

Istini za volju, dosta je lakše ako prosto pokažem neki kod kako to izgleda. Prvo, imamo sledeći HTML kod koji predstavlja formular u koji se unose podaci:

I zatim imamo akciju koja menja podatke (naravno, u pitanju je prost primer, tako da simuliam model jednom prostom listom):

Ukoliko postoji potreba, može postojati i više formulara po formi i ono što je potrebno jeste uputiti ih na one kontrolere, odnosno akcije koje su pravljene za njih.

Dakle, strane zamenjuju view-ovi, ali se glavna interakcija odvija kroz kontrolere i akcije koje su definisane nad njima. View-ovima se pristupa, odnosno oni se koriste, isključivo putem RenderView metode koja se poziva kroz akcije. Ukoliko je potrebno, view-u se mogu proslediti neki podaci, recimo kolekcija rezultata iz baze podataka ili nešto slično, što bi view trebalo da prikaže konačnom korisniku.

(Napomena: ovo je samo jako kratak i bazičan uvod u MVC Framework, i nisam želeo da zalazim u veće dubine. U kasnijim postovima ću se pozabaviti drugim aspektima MVC Framework-a, ali do tada možete slobodno pogledati postove pod tagom "MVC" na Skot Gatrijevom blogu.)

Zašto?

Osnovno pitanje koje progamerima koji trenutno rade sa ASP.NET-om pada na pamet kada se prvi put susretnu sa MVC načinom rada jeste "zašto"? Kao što sam već naveo, MVC framework ne koristi neke od dobro poznatih stvari kao što su sistem postback-a, pa samim tim i viewstate i još neke stvari. Koje su to onda mogućnosti koje čine da je MVC framework vredan truda i pažnje?

Postoji nekolikoliko razloga kojih mogu da setim:

1. Lepo formirani URL-ovi. Iako je Janko na istom januarskom sastanku UG-a pokazao kako se može lako napraviti modul za URL rewriting, MVC framework dolazi sa jako moćnim URL routing sistemom, koji je kompletno izmenljiv i ekstenzibilan.
2. Lakše testiranje koda putem unit testova. Ne samo da su kontroler, model i view odvojeni, i da se samim tim i logika koja se u njima nalazi lakše testira (pogotovo ako pričamo o kontroleru), već je i većina delova implementirana kroz interfejse. Samim tim je lakše praviti tzv. mock objekte i isto tako je moguće raditi unit testiranje bez da se pokreće čitava ASP.NET infrastruktura.
3. View može da bude aspx strana, kao što je slučaj kada se ASP.NET 3.5 Extensions paket tek instalira, ali može da bude i bilo koji drugi model rada sa podacima koji se šalju korisniku. Trenutno postoji nekoliko različitih templejt jezika u razvoju u okviru MVC Contrib projekta na CodePlex-u.
4. I ako se ne koristi bilo kakav templejt jezik ili sistem, (X)HTML kod je kompletno pod kontrolom programera.
5. Svaki korak u izvršavanju može da se presretne, zameni ili da mu se dodaju nove mogućnosti.
6. Svaki "pokretni" deo mašinerije može da se zameni. Pomenuti MVC Contrib projekat već sada sadrži dosta koda koji može da se koristi ili kao zamena ili kao dodatak na postojeće mogućnosti.

Drugo bitno pitanje je kako bi se ovakav obrazac i sistem uklopio u jednu, recimo, troslojnu arhitekturu. Jedna od prvih stvari koje su me naučili, a mislim da smo i svi naučili, što iz MSDN dokumentacija što iz kurseva, da je pravi način modeliranja aplikativnog sistema troslojna arhitektura, sa jasno određenim slojevima za pristup podacima (data access layer), za poslovnu logiku (business layer ili poslovni sloj) i konačno sloj za prezentaciju (presentation layer ili prezentacioni sloj). MVC obrazac jako podseća na ovu aritekturu, i u manjim aplikacijama, koje ili nisu već tako slojevitno dizajnirane ili takva troslojna arhitektura nije potrebna, on zaista i može da zameni istu. U postojećim aplikacijama ili aplikacijama koje iziskuju troslojnu arhitekturu, MVC obrazac može da pomogne u daljem strukturisanju prezentacionog sloja. Pošto se kao model može koristiti bilo šta, nije teško zamisliti scenario u kome bi model bio skup klasa koji bi se oslanjao na srednji sloj. Ostale dve komponente bi radile identično kao što je već opisano.

ASP.NET Unplugged

Jedna od jako bitnih stvari koju je potrebno shvatiti jeste da MVC framework nije WebForms 4.0, već samo još jedan način da se radi sa ASP.NET aplikacijama. Ukoliko imate potrebu za bilo kojim od faktora navedenih u sekciji "Zašto?", onda će vam MVC framework jako dobro doći. Ukoliko ne, ili ukoliko imate već razrađene sisteme rada sa web formama i standardnim ASP.NET mogućnostima, onda svakako možete da nastavite da koristite ASP.NET na način na koji ste do sada navikli, a koji će biti podržan i dalje.

Ovaj način je samo još jedan izbor koji imate pred sobom.

Skot Hanselman (Scott Hanselman) je okarakterisao MVC framework kao unplugged verziju ASP.NET-a. Neko voli da zaroni jako duboko i da preuzme kontrolu nad svakim aspektom svoje ASP.NET aplikacije; drugi vole jednostavnost i dobru podršku za alate koju im web forms pružaju.

Ultimativno, bitno je da postoji izbor, a na programerima je da izaberu koji model žele da koriste.

Peace. Out.

BD.