Probabil cel mai neglijat limbaj de programare, Javascript sau mai bine zis ECMAScript, a prins o amploare din ce în ce mai mare în ultimii ani și ,având în vedere noutățile pe care HTML5 le va aduce, va câștiga o și mai mare popularitate. Singura problemă a fost multă vreme aceeași ca și a CSS-ului, și anume portabilitatea de la un client web la altul. Similar, și în mediul Javascript au apărut un număr foarte mare de cadruri de dezvoltare care veneau cu librării imense de funcții pe care le puteai utiliza în site.
Cel mai nou dintre aceste cadre de dezvoltare este JQuery care prin simplitatea sa a luat pe val competitorii și a ajuns să fie promovat până și de Microsoft în cadrul produsului ASP.NET MVC.
Ce face acest framework așa de minunat? JQuery este practic librăria care a introdus noțiunea de unobtrusive javascript51, înainte de JQuery scriam:
Prin intermediul librăriei JQuery vom face în felul următor, fie la începutul documentului HTML în partea de head, fie la sfârșitul acestuia (se preferă variantă doi pentru că e mai rapidă) vom putea scrie următorul script:
...
$(document).ready(function(){
$(“#save-items”).click( save_items());
});
...
În cadrul acestui mic exemplu am atașat evenimentului onclick al butonului, funcția save_items. Pentru a ajunge la button ne-am folosit de opțiunea de a selecta elemente folosind notațiile CSS.
S-au scris cărți întregi despre această librărie și eu nu am reușit nici măcar să ating stratul superior a tot ceea ce se poate realiza, suficient să mai adaug că obținem în acest fel un document liber de orice apel de funcție javascript cu excepția etichetelor care conțin acest cod. Librăria este open-source și poate fi downloadată de la adresa http://www.jquery.com. [Bibeault2008]
Capitolul 4. Arhitectura aplicației
Arhitectura aplicației a fost puternic influențată de conceptele prezentate în capitolul 1 și anume Domain Driven Design – prin concepte precum Repository, organizarea aplicației, modelarea domeniului; principii – SRP,OCP, LSP, ISP, DI și șabloane: Unit of work, Model View Controller. Ca și privire de ansamblu structura logică a aplicației este următoarea:
Fig. 3 Structura aplicației
4.1 Infrastructura
Infrastructura oferă suportul pentru celelate straturi ale aplicației. Aici sunt conectate elementele modulelor, este implementat mecanismul care permite persistența datelor, oferă servicii care asigură securitatea aplicației și oferă funcționalități în plus clasei HtmlHelper în partea de View.
4.1.1 Configurații
Acest modul/strat al aplicației este responsabil de înregistrarea serviciilor în librăria de IoC/DI StructureMap, prin mecanismul de configurare prezentat în capitolul 3, subsecțiunea 1 și anume, serviciile au fost grupate în funcție de modulul din care fac parte prin clase care extind tipul Registry, și apoi configurate în cadrul instanței statice a tipului ObjectFactory prin mecanismul de configurare al API-ului expus de acesta. De asemenea, există posibilitatea suprascrierii acestor servicii prin fișiere de configurare xml.
În modul acesta avem un sistem decuplat, bazat pe abstracții în loc de instanțe concrete și astfel vom putea extinde ușor sau înlocui complet funcționalitățile implementate de sistemul actual odată ce iese din producție și intră în partea de mentenanță.
4.1.2 Utilități
Acest modul grupează extensii ale tipurilor de bază: boolean, string, object precum și ale tipului HtmlHelper utilizat în construirea părții de prezentare: randare de subview-uri, generare de etichete html (ancore, paginări, firul ariadnei).
4.1.3 Persistență
Modulul conține implementările necesare pentru persistarea datelor utilizând Db4o ca și bază de date. Inițializarea server-ului se face o singură dată în cadrul aplicației prin extensia Db4oHttpModule a tipului HttpModule din framework-ul Asp.NET. La sfârșitul duratei de viață a aplicației este închis serverul care deține conexiunea la baza de date.
Aplicațiile ASP.NET rulează ca şi procese în cadrul unui server precum IIS52. Acest server gestionează durata de viață a firelor de execuție create pe baza resurselor disponibile în sistem, ca urmare e greu de prevăzut când un fir de execuție va fi distrus, deci pentru fiecare fir de execuție va trebui să existe un singur client care realizează conexiunea cu baza de date altfel nu se vor putea persista datele. Acest stil de generare a unui singur context pe fir de execuție poartă numele de UnitOfWork.
Interogările asupra bazei de date se fac printr-o formă generică a șablonului Repository. Acest Repository este expus ca un serviciu în cadrul aplicației și oferă metodele: Load, SaveOrUpdate, Query, QueryPaged și Remove. Aceste metode sunt suficiente pentru a întreprinde operații asupra sistemului de gestiune a bazelor de date. Aspectul cel mai greu de realizat în implementarea acestui șablon, înainte de posibilitatea de a specifica expresii direct în cod, era numărul de condiții specifice pentru fiecare element din domeniu, întrucât trebuia extins șablonul în clase separate pentru a le încorpora. Totuși mecanismul de creare și prelucrare a arborilor de sintaxă oferit de compilatorul C# 3.5 împreună cu LINQ îmi permit să separ partea de condiționare în elemente independente de șablonul propriu zis.
NHibernate, Telerik Open Access, EntityFramework, Linq2Sql suportă prviderii necesari pentru generarea codului SQL din expresii LINQ, ceea ce va permite trecerea pe o bază de date relațională în cazul în care soluția oferită de sistemul Db4o de gestiune al bazelor de date obiectuale se va dovedi mai puțin optim. Datele existente în schimb arată contrarul, și nu cred că o astfel de măsură va fi necesară.
