Demonstrarea Principiului Soc Privind Mvc Si Controlul Asupra Html

Demonstrarea principiului SoC privind MVC și controlul asupra HTML.

Tehnologia MVC poartă mult respect pentru principiul SoC care este de înțeles chiar din denumirea MVC (Model – View – Controller). Construind aplicații mdii și mari folosind WebForms, la un moment dat se ajunge la separarea dificilă a conceptelor, codul pentru interfață se împletește cu cel pentru server, event-urile par a fi încîlcite, baza de date face parte din code behind, legătura strînsă între UI și baza de date face dificilă restructurarea. De multe ori este se ajunge la „spaghetti code”. Un eventual suport pentru aplicațiile web create utilizînd WebForms este foarte greu de realizat, necesită mult code refactoring și timp înzecit față de ușurătatea crearii inițiale.

MVC vine, cel puțin la nivel de concept cu motivarea dezvoltatorului de a separa parțile cu claritate. Fiecare parte a aplicației este răspunzătoare de îndeplinirea funcției sale. Paginile pentru UI sunt bine definite, clasele pentru modele sunt separate, codul buisness își are utlitatea lui, iar baza de date este accesibilă prin context. Dependența uneia față de alta dispare, restructurarea devine ușoară și simplu de întreșinut. Timpul de creare inițială a aplicației nu este foarte mic, însă o schimare ulterioară necesită minim efort și poate fi analizată și efectuată de către dezvoltatori cu ușurință.

Din acest punct de vedere MVC este pur Agile, la el putînd lucra mai mulți oameni odată, fiecare fiind repsonsabil de partea sa, neinterferînd cu ceilalți și ușor de a încadra codul în întreg. Din acest punct de vedere MVC este de dorit pentru aplicații la care lucrează o echipă de oameni și livrează prin metoda Agile.

Dat fiind faptul că UI este separat de controller, codul scris și generat de MVC nu diferă. Pentru MVC se folosește cod simplu HTML asupra căruia se are control în proporție de 100%. Utilizarea engine-ului Razor nu complică deloc procesul. Controlul nu se pierde. Fiecare element generat în browser va avea aceiași structură și denumire cum a fost și scrisă. La acest capitol WebForms stă mai prost. Codul generat la client este un HTML de nerecunoscut față de ceea ce a fost scris, iar elementele au denumiri dinamice, schimbătoare, incontrolabile. La acest lucru se mai adaugă și ViewState-ul pe care WebForms îl utilizează, astfel că pagina generată în browser este voluminoasă. Prin comparație, cele două pagini de mai sus generate în WebForms și MVC diferă ca volum în proporție de 4:1, mai exact codul sursă generat de WebForms este de 134 MB, pe cînd cel în MVC este de doar 32 MB. Diferențele sunt remarcabile, mai ales pentru utiizatorii de internet cu conexiune mai slabă.

Acest atu al MVC oferă posibilitatea de a fi testată fără prea multe dificultăți la nivel UI utilizînd tooluri gratuite de testare cu ar fi pluginul SeleniumIDE ce se instalează pentru FireFox și conține pași simpli de accesare a elementelor în UI prin mai multe metode, utilizînd XPATH, CSS sau ID-urile elementelor. Cazurile de testare pot fi salvate și rulate automat în orice moment. Acest lucru este mai dificil de efectuat pentru paginile WebForms. Totuși testarea urmărită este nu atît a paginilor generate în browser, cît a corectitudinii codului scris de către dezvoltator. MVC oferă testare automată a celor scrise folosind tehnologia UnitTesting. Aceasta permite ca testarea să fie executată pe partea de server, verificînd și validînd serviciile, metodele, business logica aplicației și nu numai. Acest lucru permite ca testerii să înceapă activitatea asupra aplicației mult mai devreme, chiar de la început și să minimalizeze drastic numărul de erori ce pot apărea în producție. Astfel de testare este foarte anevoioasă, practic chiar imposibilă de executat folosind WebForms. Pentru testarea căreia se vor folosi instrumente mai sofisticate și timp îndelungat de implementare.

Alegerea optimă a tehnologiei conform cerințelor pieții și tendințele actuale.

Alegerea tehnologiei pentru elaborarea unei aplicații web este determinată de cerințele clientului. De notat din start este faptul că nici o tehnologie nu este perfectă, însă unele au mai mare pondere față de altele determinate fiind de specificațiile sistemului. De obicei tehnologia nu este dictată de client ci de compania de programare, ma exact dezvoltatorii cunoscători ai domeniului.

Pentru determinarea tehnologiei optime se iau în calcul timpul de lucru, care din perspectiva clientului se echivalează în bani și performanțele care pot fi atinse cu tehnologia aleasă. Timpul de lucru însă, mai are și alte conotații, dacă clientul dorește să i se livreze aplicația iterativ (ceea ce de obicei și se întîmplă) sau dacă dorește un singur sprint; dacă se dorește suport pentru această aplicație. Toate aceste lucruri luîndu-se în cosiderație vor influența timpul de execuție și tehnologia aleasă.

Deci pentru o abordare rapidă și nu prea dificilă, se poate de ales WebForms datorită principiului RAD. Un alt principiu al fi acel al securității și ViewState-ului pe care WebForms îl oferă. Însă sunt rare momentele cînd un client nu dorește careva modificări ulterioare sau design personalizat. De aceea cu MVC acest lucru este ușor de execcutat. Astfel pentru aplicații de o mai mare anvergură vom alege MVC cînd vom avea nevoie de desing peronalizat, necesitatea de a testa aplicația și de a o încorpora cu alte tehnologii, control asupra codului HTML generat, utilizarea serviciilor API prin REST și nu numai. Nu uităm totuși de performanța obținută de MVC la genererea codului la client în pagini comparativ mai mici în cantitate ce duce la creșterea performanței la încărcarea aplicației.

Așa cum ASP.Net 5 cu MVC 6 deja nu vor mai suporta WebForms, se vede clară direcția către ce merge Microsoft. Tehnologia MVC depășește cu mult vechiul WebForms dat fiind faptul că această tehnologie întrunește cerințele comunităților de dezvoltatori și ușurează modul de implementare a aplicațiilor web. Din punct de vedere al businessului, personal aleg MVC. În toate proiectele noi în cadrul cărora sunt implicat am ales MVC. Acest lucru îmi oferă libertate în sfera implementării, integrare ușoară cu alte frameworkuri cum ar fi jQuery, Boostrap, EnityFramework și nu numai. Pentru EntityFramework 6 deja există și driver de conectare a bazei de date MySQL, astfel nu mai depindem de SQL Server. În plus, tehnologia oferită de EnityFramework, ne oferă control maxim asupra creerii bazei de date, a editării, structurii, control asupra datelor. Acest lucru este oferit prin 2 modalități:

Code First – ceea ce implică frameworkul în crearea li manipularea bazei de date și astructurii ei.

Migration – un instrument cu o deosebită utilitate, îmbunătățit ce oferă programatorilor mediul ideal de a crea baza de date, a adăuga schimbări eventuale, salvarea datelor prin cod simplu SQL, generat automat la schimbarea structurii modelului.

Dacă privim în partea asigurării calității, atunci avem posibilități nelimitate cu MVC utilizînd UnitTest pentru testarea serviciilor, controloarelor, logicii aplicații, cît și Selenium WebDrive pentru rularea de teste automate pentru interfața grafică în browser. Și ca acest lucru să fie efectuat în mod automat, serverul TeamCity, care poate fi configurat pentru a rula la orice modificare apărută pe repository, ca exemplu Git, și poate instala aplicația pe serverele de testare, instala baza de date și în cele din urmă poate porni testele scrise de dezvoltatori sau testeri în mod automat fără intervenție umană. Unicul lucru ce rămîne pentru dezvoltatori este să adauge noi funcționalități și să fixeze erorile apărute ca rezultat al rulării testelor, dacă ele există, iar pentru testeri rămîne să monitorizeze rezultatele apărute și scrierea de noi teste mai performante și mai calitative. În acest mod calitatea produsului crește și încrederea clientului nu este înșelată.

Livrarea aplicațiilor Web utilizînd pachet de instalare.

Crearea de web aplicații pentru clienți presupune și instalarea lor pe serverele necesare. Acest lucru se poate face în mai multe moduri:

xCopy – se face prin copierea manuală sau automată a fișierelor necesare pe server.

OneClick Publish – o utilitate din Visual Studio de a livra doar fișierele precompilate necesare rulării aplicației.

Pachet de instalare – utilizarea unor unelte de asamblare a pachetelor de instalare a web aplicațiilor pe server.

Pentru a instala web aplicația putem alege oricare din metode, totuși va fi aleasă metoda care corespunde cerințelor clientului. Intrumente pentru a crea pachet de instalare sunt numeroase începînd cu cele gratis și pînă la cele contra unor sume fabuloase. Totul depinde de cerințele clientului. În ceea ce urmează voi încerca să descriu modul de livrare a web aplicațiilor utilizînd un pachet de instalare oferit în mod gratuit și care se instalează ca o extensie în IDE-ul Visual Studio. Acesta poartă denumirea de Setup Project și este ușor de utilizat avînd cu sine și interfață grafică cu dialoguri. O altă versiune a sa poartă denumirea de WiX, el fiind mult mai evoluat, oferind acces la asamblarea pachetului prin intermediul limbajului propriu cu tag-uri XML. Dificultatea constă în însușirea limbajului, însă există și pentru el inerfață comodă dezvoltatorului conta plată.

Așadar se instalează SetupProject pentru Visual Studio. Pentru aplicații web se crează un nou proiect WebSetupProject.

Figura 3.4.1 Adăugarea unui proiect de creare a pachetului de instalare.

Acest wizard va adăuga un nou proiect pentru instalare. Proiectul oferă posibilitatea de a efectua următoarele acțiuni după cum se vede și în figura de mai jos:

Figura 3.4.2. Componentele oferite de proiect.

File System – secțiune ce cuprind fișierele ce vor fi instalate de către pachet. Aceasta oferă posibilitatea de adăuga fișiere, foldere (sau foldere speciale cum ar fi Program Files), fișiere asamblate sau proiect întreg ce va trage după sine toate dependențele fără ca programatorul să se îngrijească de acest lucru.

Registry – regiștrii ce vor fi adăugați/modificați în timpul instalării.

File Types – tipuri de fișiere utilizate.

User Interface – crearea pașilor de instalare utilizînd dialogurile predefinite. Dialogurile predefinite nu sunt întotdeauna destule sau nu corespund nevoilor, de aceea se poate de creat dialoguri personalizate, lucru ce vom explica puțin mai jos.

Custom Actions – acțiuni scrise în cod C# ce vor fi executate la fazele instalării cum ar fi Install/Commit/Rollback/Uninstall. Aceste acțiuni se vor adăuga ca proiect clasă librărie. Codul se poate analiza în Anexa 3.

Launch Conditions – condiții speciale de verificare a cerințelor de sistem înainte de a rula installerul. Este posibilă adăugarea condițiilor de verificare prin căutarea după anumiți regiștri, calea către un anumit fișier sau o anumită aplicație.

Crearea unui pachet de instalare prietenos cu utilizatorul necesită niște pași de instalare personalizați, ceea ce nu mereu se gasesesc în dialogurile predefinite. Figura de mai jos prezintă dialogurile automat adăugate și cele ce pot fi adăugate și configurate manual.

3.4.3. Dialogurile predefinite oferite de proiect.

Patru din aceste dialoguri prezentate în chenarul Add Dialog sunt dialoguri create de mine personal și reprezintă studiul meu asupra acestui lucru. Aceste dialoguri sunt: Textboxes and Dropdown – dialog ce-mi permite să am într-o pagină și textboxuri și dropdown cu date predefinite pentru selectare, Custom Folder și Custom Web Folder – dialoguri ce-mi permit să aleg/creez/șterg un folder pentru instalare sau alte nevoi speciale, User Password – dialog cu 3 textboxuri pentru numele de utilizator, parolă și confirmarea ei cu validare asupra coencidenței parolelor. Din cauză că informație este foarte puțină la acest capitol, am fost nevoit sa sap adînc și sa caut modalități de a crea dialogurile mele personale cu validările proprii. Un instrument foarte util în acest scop este Orca ce poate fi instalat cu ușurință pe Windows. Acest instrument oferit gratuit de Microsoft poate deschide fișiere de tip .msi și .wid. Conținutul acestor fișiere este redat în formă de tabele cu dependențe între ele. Astfel înainte de a redacta vreun dialog, este nevoie de a studia lista tabelelor ce se includ în installer Microsoft, a variabilelor predefinite și acțiunile asupra lor.

La compilare, vor fi asamblate mai întîi proiectele ce țin de aplicație ca mai apoi să fie asamblat și proiectul de instalare. În rezultat vom obține două fișiere, unul .msi și al doilea fișier executabil legat cu primul. Executarea fișierului .exe va inițializa fișierul .msi și va deschide dialogurile pe care le-am adăugat la crearea proiectului. În figura de mai jos putem vedea un exemplu de executare a pachetului de instalare.

Figura 3.4.4. Executarea pachetului de instalare și vizualiazarea dialogurilor.

Cu ajutorul acestui tip de livrare a aplicației obținem careva beneficii:

Programatorul nu interferează cu serverele de producție.

Administratorii din partea clientului au libertate în alegerea de stocare a datelor aplicației și bazei de date pe servere securizate interne.

Livrarea doar a fișierelor compilate și nu a codului sursă.

Configurarea accesului la folderele de instalare.

Executarea diferitor scripturi către baza de date sau rularea altor procese independente utilizînd Custom Actions.

Acest proiect poate fi utilizat atît pentru MVC cît și pentru Web Forms. Modul de lucru este asemănător. Este nevoie doar de adăugat fișierele necesare compilate și cele pentru afișare HTML, iar procedura rămîne neschimbată. Diferența vizibilă va fi la marimea fișierelor .msi rezultate, Web Forms ocupînd un spațiu mai mare pe disc.

Сonсluzii privind Сapitolul III.

Fiecare tehnologie își are plusul său și performanțele la care poate fi adusă o aplicație web. Tehnologia WebForms continuă să mai fie folosită pentru principiul RAD al rapidității cu care se poate crea o interfață ușoară. Numeroasele controloare oferă cam orice și-ar dori un client să vadă în browser, luînd în considerație și alte tehnologii terțe care pot adăuga controloare contra unor sume pentru pachetele lor. Un alt principiu pentru care s-ar alege WebForms este ViewState și/sau SessionState, stabilitatea paginilor între PostBack-uri sau chiar pentru securitatea pe care o oferă.

Alegerea unei tehnlogii aduce după sine și întebări de genul: întreținerea site-ului, configurarea lui, extinderea, personalizarea, integrarea cu alte tehnologii noi dorite la ora actuală. Desigur la aceste întrebări MVC are răspuns. Dinamica acestei tehnologii nu lasă urme de îndoială: integrarea ușoară cu multe platforme, design personalizat, principii de dezvoltare bine definiți, libertatea în alegerea bazei de date, a platformei de rulare și mulți alți factori pe care comunitatea internațională de dezvoltatori și-a dorit-o și pe care Microsoft a luat-o în considerație.

Modul de livrare al aplicației poate fi ales după preferințe și/sau după cerințele clientului. Ori că se optează pentru o extensie Visual Studio IDE, ori că se optează pentru un instrument de asamblare a unui pachet de instalare gratis sau chiar cu plată, dezvoltatorul are libertatea tehnologiilor. Pachetele de instalare par mai sigure și mai simple. Eliberează clientul de securizarea datelor interne împotriva la compania de producere a softului, nu-și expune structura internă, decuplează dezvoltatorul de dependența de platformă și generalizează funcționalitatea, pachetul putînd fi instalat pe orice fel de sistem de operare, dacă permite tehnologia.

СONСLUZII

ASP.NET oferă un model de programare și o infrastruсtură prin intermediul сărora se pot dezvolta atât apliсații web сât și serviсii web. Prinсipalele сaraсteristiсi ale ASP.NET sunt următoarele: Apliсațiile ASP.NET sunt сompilate. Unul din dezavantajele ASP-ul сlasiс îl сonstituia faptul сă pagină web сonținea sсripturi, сod сe trebuia interpretat și apoi exeсutat; сu ASP.NET сodul, folosind metode de сaсhe, este deja сompilat și gata pentru exeсuție; apliсațiile ASP.NET sunt сompilate în două faze: prima fază în сare сodul С# sau VB.NET (și altele) este сompilat într-un assembly сe сonține сod intermediary IL (aсesta сompilare poate avea loс în momentul primei сereri sau sursele pot fi deja сompilate) și a doua realizată de JIT сhiar înaintea exeсuție propriu-zise a paginii și сonstă în tranformarea сodului IL în сod nativ optimizat pentru sistemul pe сare se afla serverul web; o apliсație web nu este сompilata de fieсare dată сând o pagină sau un serviсiu web este сerut, în sсhimb se folosește o metodă de păstrare (сaсhe) a сodului deja сompilat (JIT); сodul IL este reсompilat de fieсare dată сând sursele sunt modifiсate;

ASP.NET este multi-limbaj.Se pot alege oriсe limbaj pentru a dezvolta o apliсație web; asta pentru сă rezultatul сompilării va fi сod IL adiсă un сod sсris pentru .NET și poate rula în interiorul unui mediului protejat oferit de СLR; O apliсație ASP.NET folosește mediul de exeсuție oferit de СLR. Aсest luсru impliсa: • Managementul automat al memoriei; • Siguranța tipurilor: сând se сompilează o apliсație în assembly-ul сonstruit se adauga informații detaliate despre сlasele folosite (metode, date, loсalizare etс.) astfel înсât apelul unor metode, să nu neсesite informații suplimentare deсât aсelea oferite în metadata; • Multi-threading: o apliсație web poate neсesita mai multe fire de exeсuție; thread-urile pot fi folosite pentru a exeсuta operații asinсrone (сitirea unui fișier, apelul unui serviсiu web) sau pentru a exeсuta o operație în mod сontinuu pe durata de viață a apliсației web (de exemplu un un fir сu prioritate sсăzută сare trebuie să salveze date la intervale regulate); ASP.NET este orientat obieсt. Se poate folosi oriсe сlasă pusă la dispoziție de .NET Framework și se poate utiliza oriсe prinсipiu OOP pentru сare exista suport. Сel mai bun exemplu este aсela al сontroalelor server-side: сontroalele pot fi сreate și modifiсate programatiс astfel înсât să răspundă într-un anumit fel la evenimente sau să aibă un anumit aspeсt; Apliсațiile ASP.NET sunt ușor de instalat și сonfigurat. De сele mai multe instalarea unei apliсații ASP.NET înseamnă doar сopierea fișierelor apliсației într-o mapă pe disс unde este mapat un direсtor virtual al IIS. Сonfigurarea este la fel de simplă: fieсare apliсație сonține un fișier în format XML web.сonfig în сare sunt ținute setările; poate fi modifiсat în timpul rulări apliсației iar apliсarea lor se faсe automat.