Entity Framework Si Linq CU Aplicatii In Baze DE Date Medicale Exploatate In Regim Saas

Medicina

Entity Framework Si Linq CU Aplicatii In Baze DE Date Medicale Exploatate In Regim Saas

Byadmin ianuarie 1, 2024

ENTITY FRAMEWORK ȘI LINQ CU APLICAȚII ÎN BAZE DE DATE MEDICALE EXPLOATATE ÎN REGIM SAAS

CUPRINS

INTRODUCERE

CAPITOLUL I

Limbaje de interogare bazate pe SQL

Limbaje de interogare “XML

Tipuri de date

Instrucțiuni de procesare și comentarii

Stocarea marcajelor

Stocarea și recuperarea documentelor

Stocarea documentelor în sistemul de fișiere

Sintaxa “XML

Declarația “XML

Construirea prologului unui document “XML

Crearea corpului documentului

Date caracter

Marcajul

Formarea structurilor logice în “XML

Cum formează “XML” structurile fizice

Etichete de pornire și etichete de încheiere

Tipuri de elemente

CAPITOLUL II

Ce este LINQ

LINQ și C

Fundamente LINQ

CAPITOLUL III

ASP.NET introducere

Ce este ASP.NET MVC

Controller-ul

Acțiunile unui controller

View-ul

Modelul

Anatomia unei aplicații ASP.NET

Avantaje ASP.NET MVC

Concluzii

CAPITOLUL IV

Ce este SOA

Nevoia de SOA

Beneficii ale SOA

Proprietăți ale implementarii SOA

Ciclul de viață SOA

Modelare

Asamblare

Implementare

Administrare

CAPITOLUL V

Limbajul de programare C# și trăsăturile lui

Simplitate

Modernitate

Orientat pe obiecte

Type safe

Interoperabilitate

Scalabilitate și update

C# este un mediu RAD

Alte facilitati C

Despre limbajul C# și platforma .NET

CAPITOLUL VI

Prezentarea generală a limbajului SQL

Scrierea comenzilor SQL

Instrucțiuni pentru definirea datelor

Instrucțiuni pentru selecția datelor

Funcțiile agregat

Asocierile ( JOIN)

Combinările (UNION)

Instrucțiuni pentru manipularea datelor

Cereri de interogare imbricate

CAPITOLUL VII

Aplicatie practica – descriere

Concluzie

Bibliografie

INTRODUCERE

Când ești medic iar un pacient vine la tine acuzând dureri insuportabile vei face tot ce poți pentru a-l ajuta. Ca să îl poți ajuta trebuie să te miști rapid . Ca să te miști rapid trebuie să ai la dispoziție instrumente și aparatură . Calculatorul a devenit un instrument de lucru indispensabil pentru un medic . datele pacientilor, , actualizarea lor se pot face și accesa cel mai simplu cu ajutorul calculatorului. De aceea ne-a venit ideea unei aplicații cu ajutorul căreia să eficientizam timpul de lucru al medicului și , nu în ultimul rând , să scurtăm durată de așteptare și , deci implicit , suferința pacienților .

Așa a luat naștere aplicația noastră .

Aplicația funcționează ca o rețea, la care utilizatorii pot avea acces doar pe baza înregistrării. Proiectul urmărește crearea unui registru electronic de evidență a bolnavilor și a afecțiunilor acestora .

Medicii vor putea accesa aplicația pe baza unui nume de utilizator unic și a unei parole. La fiecare pacient înregistrat în sistem, aplicația va genera un document pdf cu datele de identificare ale pacientului , cum ar fi nume, prenume, cnp, și constatările medicului în urma efectuării consultației . dacă pacientul dorește, ulterior să vizualizeze rezultatele vizitei medicale, el / ea se poate conecta la aplicație , user name-ul aferent, parolă fiind CNP-ul acestuia, și totodată poate și printa documentul PDF, dacă dorește .

Aplicația este destinată informatizării activității cabinetelor medicilor . Sistemul automatizează gestiunea electronică a pacienților și a întregii activități medicale desfășurate de personalul cabinetului.

La aplicație se pot conecta trei tipuri de utilizatori : administratori, medici/asistente și pacienți. Administratorul poate adăuga utilizatori noi după cum urmează :

Medic/ asistenta.

Pacienți.

Alți administratori .

Alegerea acestei teme a fost influențată de faptul că ambii părinți sunt medici de familie și am văzut de-a lungul timpului cât este de dificil să te poți descurca cu un număr mare de pacienți într-un timp scurt.

Sperăm că această aplicație , pe care ne dorim să o îmbunătățim pe viitor , să scurteze timpul de așteptare al pacienților și să ofere mai mult timp liber medicului pentru a putea găsi tratamentul eficient.

CAPITOLUL I

Limbaje de interogare bazate pe SQL

Limbajele de interogare bazate pe SQL folosesc fraze SELECT modificate, iar rezultatele sunt transformate în “XML”. Există câteva limbaje particulare de acest tip și cel mai simplu dintre acestea folosește fraze SQL imbricate (nested), care sunt transformate direct în “XML” imbricat (nested) conform cu maparea relațional-obiectuală. Un alt limbaj de acest tip folosește obiecte SQL 3, de asemenea transformate direct în “XML”. Un alt limbaj folosește fraze OUTER UNION și marcaje speciale pentru a determina cum sunt transformate rezultatele în “XML”.

Limbaje de interogare “XML”

Spre deosebire de limbajele de interogare bazate pe șabloane sau bazate pe SQL, care pot fi folosite numai cu baze de date relaționale, limbajele de interogare “XML” pot fi folosite pentru orice document “XML”. Pentru a folosi acest tip de limbaje cu baze de date relaționale, datele din baza de date trebuie să fie modelate ca “XML”.

Cu XQuery, poate fi folosită fie maparea bazată pe tabele fie maparea obiectual relațională. Dacă este folosită o mapare bazată pe tabele, fiecare tabelă este tratată ca un document separat și în fiecare interogare sunt specificate uniri între tabele, ca în SQL. Dacă este folosită o mapare obiectual-relațională atunci ierarhiile de tabele sunt tratate ca un singur document și sunt specificate uniri în mapare. Se preconizează că mapările bazate pe tabele vor fi utilizate în majoritatea implementărilor, în detrimentul bazelor de date relaționale, deoarece se consideră că sunt mai ușor de implementat și mai bine cunoscute de utilizatorii SQL.

Cu XPath, o mapare obiectual-relațională trebuie să fie folosită pentru a executa interogări peste mai multe tabele. Aceasta se întâmplă deoarece XPath nu suportă unirile între documente. Astfel, dacă ar fi folosită o mapare bazată pe tabele, ar fi posibilă interogarea unei singure tabele la un moment dat.

Tipuri de date

“XML” nu suportă prea multe tipuri de date. Cu excepția entităților neanalizate, toate datele dintr-un document “XML” sunt text, chiar dacă reprezintă alt tip de date, cum ar fi datele calendaristice sau integer. În general soft-ul de transfer date va transforma textul (din documentul “XML”) în alte tipuri de date (în baza de date) și invers.

Softul determină ce conversii sunt necesare și există două metode pentru efectuarea acestora. Prima metodă constă în determinarea de către software a tipurilor de date din schema bazei de date, deoarece aceasta este accesibilă la rulare. (Schema “XML” nu este neapărat accesibilă la rulare sau s-ar putea sa nu existe.) În a doua metodă utilizatorul specifică tipul de date. Acesta poate fi scris de către utilizator sau generat automat dintr-o schemă a unei baze de date sau dintr-o schemă “XML”. Atunci când sunt generate automat, tipurile de date pot fi recuperate din schemele bazelor de date și din anumite tipuri de scheme “XML”.

Formatele de text recunoscute în momentul conversiilor pot constitui o problemă atunci când se transferă date din “XML”, la fel și formatele care se pot crea atunci când se transferă date către “XML”. În cele mai multe cazuri, numărul de formate de text care sunt suportate de un tip de dată este limitat la unul anume sau la cele suportate de driverul JDBC. Datele pot cauza multe probleme pentru că gama de formate posibile este foarte mare, iar numerele cu diferitele lor formate internaționale pot cauza de asemenea probleme.

Instrucțiuni de procesare și comentarii

Instrucțiunile de procesare și comentariile nu fac parte din datele dintr-un document “XML” și majoritatea soft-urilor de transfer de date nu le pot manipula. Totuși ele pot apărea aproape oriunde într-un document “XML” și de aceea nu se integrează ușor în mapările bazate pe tabele și cele obiectual relaționale. O soluție total ineficientă într-o bază de date relațională este adăugarea unor tabele pentru instrucțiuni de procesare și comentarii, adăugarea de chei străine la aceste tabele pentru toate celelalte tabele, și verificarea acestor tabele de fiecare data când se procesează o altă tabelă. Astfel majoritatea soft-urilor de transfer de date le înlătură.

Stocarea marcajelor

În anumite situații este indicată stocarea elementelor cu conținut mixt în baza de date fără a se efectua analiza completă. Când este realizat acest lucru, marcajul este realizat cu caractere de marcare. Totuși apare o problemă la stocarea caracterelor de marcare care nu sunt folosite pentru marcaj. În fișierul “XML”, acestea sunt stocate folosind entitatile lt, gt, amp, quot, și apos. Acest lucru poate fi făcut și în baza de date.

Stocarea și recuperarea documentelor

Ca sa stocam documentele „“XML”” avem la dispozitie doua metode de baza: fie salvarea lor în sistemul de fisiere, drept un „BLOB” in interiorul unei baze de date relaționale si acceptarea restransa a funcționalități “XML” , fie depozitarea lor într-o bază de date „“XML””.

Stocarea documentelor în sistemul de fișiere

In cazul in care se lucrează cu un numar mic de documente, cea mai facila metoda de stocare este cea in sistemul de fisiere. Instrumentele folosite sunt de tipul „grep” si „sed” pentru interogarea respectiv modificarea lor. Căutările textului complet în documentele „“XML”” nu sunt exacte, deoarece nu se poate intelege utilizarea entitatilor si a marcajului de text.Aceste inexactitati sunt neglijabile pentru un sistem mic. Dacă se dorim un simplu control al tranzacțiilor, documentele pot fi gestionate cu o versiune de control a sistemului: „CVS”, „RCS”.

Sintaxa “XML”

„“XML”” este alcatuit din două metalimbaje, care sunt descrise în cadrul aceluiași document. Primul metalimbaj este un set de reguli pentru crearea corecta a documentelor „“XML””, iar al doilea este un set de reguli pentru definirea tipului documentului „“XML””, sau „DTD”, care permite ca organizarea documentului „“XML”” să corespunda unor constrângeri și să se supuna constrângerilor. Distincția dintre aceste două limbaje este deseori neclară, deoarece un document “XML” complet presupune măcar existența opțională a unui Document Type Definition, indiferent dacă acesta este de fapt prezent sau nu. Pentru a complica și mai mult lucrurile, un Document Type Definition poate fi compus din două părți, o submulțime internă și o submulțime externă. Aceasta parte studiază documentul “XML” fără a insista prea mult asupra Document Type Definition -ului, deoarece un document “XML” poate fi creat și fără a face referiri la un Document Type Definition. Din motive de performanță, multe documente “XML” vor fi utilizate fără a le valida în raport cu Document Type Definition ul, chiar dacă Document Type Definition -ul este disponibil. În cazul conexiunilor lente, citirea dintr-un Document Type Definition situat pe un alt sistem poate fi foarte înceată, iar datorită faptului că un Document Type Definition poate conține referințe la alte documente, rezolvarea tuturor referințelor externe poate dura exagerat de mult chiar și în cazul conexiunilor de mare viteză. Utilizatorii sunt obișnuiți ca documentele “HTML” să fie încărcate incremental, deci pot citi înainte ca docum” , fie depozitarea lor într-o bază de date „“XML””.

Stocarea documentelor în sistemul de fișiere

In cazul in care se lucrează cu un numar mic de documente, cea mai facila metoda de stocare este cea in sistemul de fisiere. Instrumentele folosite sunt de tipul „grep” si „sed” pentru interogarea respectiv modificarea lor. Căutările textului complet în documentele „“XML”” nu sunt exacte, deoarece nu se poate intelege utilizarea entitatilor si a marcajului de text.Aceste inexactitati sunt neglijabile pentru un sistem mic. Dacă se dorim un simplu control al tranzacțiilor, documentele pot fi gestionate cu o versiune de control a sistemului: „CVS”, „RCS”.

Sintaxa “XML”

„“XML”” este alcatuit din două metalimbaje, care sunt descrise în cadrul aceluiași document. Primul metalimbaj este un set de reguli pentru crearea corecta a documentelor „“XML””, iar al doilea este un set de reguli pentru definirea tipului documentului „“XML””, sau „DTD”, care permite ca organizarea documentului „“XML”” să corespunda unor constrângeri și să se supuna constrângerilor. Distincția dintre aceste două limbaje este deseori neclară, deoarece un document “XML” complet presupune măcar existența opțională a unui Document Type Definition, indiferent dacă acesta este de fapt prezent sau nu. Pentru a complica și mai mult lucrurile, un Document Type Definition poate fi compus din două părți, o submulțime internă și o submulțime externă. Aceasta parte studiază documentul “XML” fără a insista prea mult asupra Document Type Definition -ului, deoarece un document “XML” poate fi creat și fără a face referiri la un Document Type Definition. Din motive de performanță, multe documente “XML” vor fi utilizate fără a le valida în raport cu Document Type Definition ul, chiar dacă Document Type Definition -ul este disponibil. În cazul conexiunilor lente, citirea dintr-un Document Type Definition situat pe un alt sistem poate fi foarte înceată, iar datorită faptului că un Document Type Definition poate conține referințe la alte documente, rezolvarea tuturor referințelor externe poate dura exagerat de mult chiar și în cazul conexiunilor de mare viteză. Utilizatorii sunt obișnuiți ca documentele “HTML” să fie încărcate incremental, deci pot citi înainte ca documentul să fie încărcat în totalitate, dar analizatoarele “XML” de validare nu permit afișarea documentului decât în cazul în care acesta este valid, deci documentul va apărea pe ecranul utilizatorului numai în momentul în care este încărcat în totalitate. Acest lucru poate fi supărător. Totuși, fiecare document este creat având în minte un Document Type Definition, indiferent dacă Document Type Definition-ul este explicit sau nu. Chiar și la crearea documentelor fără un Document Type Definition, trebuie să avut în vedere un fel de Document Type Definition empiric pe măsură ce este creat documentul, deoarece un Document Type Definition descrie o structură de date.

Declarația “XML”

Fiecare document “XML”, ar trebui să înceapă cu o declarație “XML” care identifică fișierul ca fiind un fișier “XML” și identifică, de asemenea, versiunea “XML” utilizată în documentul respectiv. Caracterul opțional este datorat numai faptului că pe Web există multe fișiere “HTML” și SGML care corespund perfect unui document “XML” construit corect. De asemenea, declarația “XML” este locul unde se declară codificarea și dacă documentul este sau nu autonom. Ordinea din fragmentul următor este obligatorie cu toate că atributele encoding și standalone sunt ambele opționale:

<?”XML” version=”1.0”encoding=”ISO-8859-1”standalone=”yes”>

Codificările permit identificarea cărui dintre multiplele seturi de caractere va fi utilizat în document. Acest lucru este important deoarece, spre deosebire de “HTML”, care implică ASCII, și obligă la folosirea numelor ASCII, “XML” permite vorbitorilor de Hindi, de exemplu, să utilizeze codificarea lor și să facă textul și mediul de editare lizibil și pentru persoanele obișnuite care pot fi autori “XML”. Sau, un autor chinez poate să prefere caracterele chinezești în etichete și în conținut cu câteva limitări bazate pe regulile limbajului în sine, se pot utiliza moduri de scriere și ideograme atât în numele etichetelor cât și în conținut.

Construirea prologului unui document “XML”: Declarația tipului documentului (Document Type Declaration,”DTD”)

Prima parte a unui document “XML” conține mai multe instrucțiuni. Prima este declarația “XML”, care sustine că documentul ce urmeaza este “XML”. A doua, declarația tipului documentului („DTD-Document Type Declaration”), este folosita pentru a arata definiția tipului documentului („DTD-Document Type Declaration”) utilizata de un anume document. Din nefericire acronimul „DTD” se poate folosi si ca definitie si ca declaratie. „DTD” este o prescurtare a „Document Type Definition”. Într-un document “XML” nu pot exista mai multe declarații la tipul documentului,prin urmare se introdce chiar în instanța documentului. Din moment ce putem combina mai multe „DTD –uri” ca sa formam un singur document, aceasta faciliteaza controlul încărcării „DTD –urilor” în fiecare document.

Declarația tipului documentului (DOCTYPE) consta din doua segmente, amandoua opționale. Primul segment se referă la un „DTD” extern și foloseste cuvintele cheie: PUBLIC sau SYSTEM pentru a marca o intrare dintr-un catalog, respectiv un URI. Se pot specifica ambele segmente deodata fara al doilea cuvant cheie, in cazul în care cataloagele nu sunt implementate în procesorul “XML”:

<!DOCTYPE denumire_doc PUBLIC “{catalog id}”>

<!DOCTYPE denumire_doc PUBLIC “{catalog id}” “{uri}”>

<!DOCTYPE denumire_doc SYSTEM “{uri}”>

Cel de-al doilea segment al declarației DOCTYPE admite introducerea submulțimii interne a unui „DTD” direct în document.In „DTD-ul” intern genul de informatie care poate fi introdusa este restrictionat. Submulțimea internă a unui „DTD” este încadrată de paranteze drepte, astfel:

<!DOCTYPE denumire_doc [ {declarații } ]>

De asemenea, cele două pot fi intercalate, facilitand adăugarea anumitor tipuri de declarații și entități în orice mod:

<!DOCTYPE denumire_doc PUBLIC “{catalog id}” “{uri}” [ {declarații} ]>

Submulțimea internă este redata ca mai jos:

<!DOCTYPE denumire_doc PUBLIC “{catalog id}” “{uri}” [

{declarații}

]>

Declarația DOCTYPE trebuie să utilizeze numele elementului rădăcină al Document Type Definition -ului fie acesta intern sau extern, ca fiind câmpul etichetat denumire_doc din exemplele anterioare. Deci dacă numele elementului rădăcină al Document Type Definition -ului este Test, declarația DOCTYPE ar trebui să înceapă astfel:

<!DOCTYPE Test …>

Manualul de codare indică autorilor ce trebuie trecut în DOCTYPE. Un proiectant Document Type Definition ar trebui să furnizeze un astfel de document sau o foaie de codare fiecărui autor. De asemenea, se poate crea un Document Type Definition master care apelează părțile Document Type Definition necesare, lucru care seamănă cu comenzile dintr-un meniu. Atunci când se obține o combinație de funcționalități care permite crearea structurii documentului de care este nevoie, se poate publica Document Type Definition -ul rezultat și înlătura neplăcerea refacerii pentru fiecare document nou.

Crearea corpului documentului

Amestecul de marcaje si date caracter formeaza corpul unui document “XML”. Inceputul este alcatuit numai din marcaje dar care trebuie sa fie insotite si de date pentru ca altfel ar fi ca niste curii goale fara date. Urmeaza corpul documentului care conține aproape tot ceea ce e important din punct de vedere al unei aplicații împrăștiate printre marcaje.

Date caracter

Un „DTD” poate declara diverse tipuri de date care pot fi folosite într-un document, insa tipul de date predefinit este „CDATA” intotdeauna, pentru date de tip caracter. Codarea indică ce tip de dată poate fi introdusa în fiecare atribut sau câmp cu conținut de elemente. Daca tipul de date este „CDATA”, în câmp se pot pune aproape orice daca nu conține marcaje în afara de secvența escape.

Este pe deplin posibilă construirea unui Document Type Definition care să nu conțină text în interiorul elementelor. În schimb, se pot pune datele semnificative în interiorul atributelor asociate fiecărui element, care pot fi toate declarate ca fiind vide sau având numai conținut element. Acest lucru se face uneori pentru a converti un document utilizând un standard de codificare cum ar fi MARC, care este în esență un format binar, la “XML”.

Marcajul

Ansamblul de date non-caracter dintr-un „XML” formeaza marcajul . In tabelul de mai jos sunt prezentate formele care pot fi luate de marcaje dupa cum urmeaza:

Daca marcajul începe cu caracterul <, acesta se se încheie cu caracterul >, sau daca incepe cu caracterul &, se încheie cu caracterul “;”.

Formarea structurilor logice în “XML”

Ca sa aratam structura logica intr-un document tip „XML” folosim imbricarea elementelor ca unic mecanism utilizat. Etichetele de inceput și sfarsit din text transmit procesorului “XML” că un nod a fost întâlnit. Dacă o alta eticheta de inceput este intalnita inaintea cele de incheiere corespunzatoare, procesorul „XML”deduce ca aceasta este fie un nod nou in arbore, fie o frunza. Dacă nu se intalneste o nouă etichetă de inceput și ci una detă de încheiere, atunci procesorul va cauta o alta eticheta de inceput sau de sfarsit in mod iterativ.Pe aceasta regula se azeaza prelucrarea treptata. Dacă documentul este validat de procesor, atunci la fiecare nod i se poate lega o regulă care să deduca ce tip de conținut poate apărea în el. Daca nu are nici un continut,o etichetă vidă devine, o frunză.

Majoritatea structurilor de date conținute într-un document “XML” pot fi accesate secvențial fără a construi structura în memorie. O etichetă de pornire începe un nod sau o frunză, iar eticheta de încheiere corespunzătoare îl(o) încheie. Orice etichete întâlnite între o etichetă de încheiere corespunzătoare ei încep un nod sau o frunză nouă. Acest principiu reprezintă baza lui SAX și a altor procesoare “XML” conduse prin evenimente.

Restul structurii logice a documentului este definit prin atributele asociate fiecărui element. În plus, structura logică poate diferi în funcție de conținutul secțiunilor condiționale din cadrul documentului sau al componentelor sale.

Cum formează “XML” structurile fizice

Imbricarea entităților este singurul mecanism utilizat pentru a arăta structura fizică dintr-un document “XML”. Definițiile de entități întâlnite în fluxul de text îi comunică procesorului “XML” că a fost găsită o altă entitate.

Există multe tipuri de entități, de la entitățile mici care formează caractere individuale, cum ar fi:   (spațiu), până la entitățile externe care permit încorporarea într-un document porțiuni din alte documente “XML” sau includerea într-un document a referințelor la date neanalizate, cum ar fi fișiere multimedia pentru redarea ulterioară de către un agent utilizator.

Un document “XML” este o colecție de astfel de entități. Fiecare din aceste subentități trebuie să fie completă în sine. Aceasta înseamnă că, deoarece structura documentului ca întreg trebuie să fie un arbore simplu, fiecare subentitate trebuie să fie un singur nod sau trebuie să fie, de asemenea, un arbore simplu. Structuri mai mari se pot construi prin adăugarea nodurilor sau a arborilor subentitate ca porțiuni ale arborelui mai mare.

Etichete de pornire și etichete de încheiere

Cele doua tipuri de etichete utilizate in “XML” ,sunt cele cu conținut și cele vide. O eticheta de pornire cuplata cu o eticheta de incheiere formeaza eticheta cu continut.Numele elementului incadrat intre paranteze unghiulare formeaza o eticheta de pornire.Caracterul slash precede eticheta de incheiere care este incadrata intre paranteze unghiulare.Eticheta de pornire poate contine atribute in timp ce in eticheta de incheiere nu putem trece atribute. Mai jos este prezentata o etichetă cu conținut:

<titlu subtitlu=”0 călătorie acasă” >Dus-întors</titlu>

Eticheta de inceput se aseamănă mult cu etichetele “HTML” standard și nu ar trebui să genereze alte probleme cu exceptia construirii corecte, care cere ca ele să se imbrice într-adevăr una în cealaltă. Exemplul de jos este gresit deoarece etichetele alterneaza intre ele:

<bold><italic>TEXT ACCENTUAT</bold></italic>

Constructia de mai sus desi este frecventa în “HTML”,in “XML” nu este permisa. Etichetele trebuie imbricate corect, ca în exemplul următor:

<bold><italic>TEXT ACCENTUAT</italic></bold>

Acum etichetele sunt imbricate corect. Trebuie închisă fiecare etichetă care începe în contextul unei anumite etichete (sau a mai multor etichete) înainte de închiderea contextului etichetei respective.

Etichetele vide au disponibil un format special, cu toate că aceeași schemă, etichetă de pornire/ etichetă de încheiere, poate fi utilizată atâta timp cât se ține cont de faptul că nu trebuie pus nici un fel de conținut între eticheta de pornire a elementului vid și eticheta de încheiere care urmează imediat după ea. De asemenea, poate exista preocuparea că este posibil ca documentul “XML” să fie vizualizat cu un browser Web obișnuit, deoarece etichetele de încheiere pentru elementele care arată ca etichete “HTML” vide pot duce la blocarea browserului sau la un comportament ciudat al acestuia.

Tipuri de elemente

În mod surprinzător, la validare nu este o eroare utilizarea unui element de un tip care nu a fost declarat, cu toate că este posibil ca analizorul să emită un advertisment. De fapt, permițând în interiorul unor elemente alte tipuri de elmente nedeclarate, indiferent de ceea ce spune modelul lor de conținut, se poate suplimenta Document Type Definition -ul unui document cu elemente din alte zone de nume. Deci, tot ce rămâne de făcut este utilizarea elementului nedeclarat într-o manieră exactă, construită corect, identificând pe cât posibil zona de nume de unde provine. În termeni “XML”, a fi construit corect este un alt mod de a spune că acel element formează un arbore sau o ramură a unui arbore care este completă în sine. Acest lucru este necesar deoarece “XML” permite construirea de documente mai mari din unele mai mici și este un element cheie pentru utilizarea “XML” pe Web. Fiecare element dintr-un document “XML” valid a fost definit în Document Type Definition -ul asociat acelui document prin declarația DOCTYPE. Document Type Definition -ul declară următoarele:

• Numele efective ale elementelor

• Regulile utilizate pentru a determina care elemente se pot imbrica în alte elemente și în ce ordine

• Atributele posibile și valorile lor prestabilite sau constante

• Valorile caracter ale tipurilor enumerate

• Entitățile neanalizate utilizate în document și modul în care sunt referite prin nume

• Codificările de limbă utilizate în document

• Alte informații importante pentru prelucrarea și redarea documentului

Respectând aceste reguli se pot crea documente în concordanță cu șablonul pe care proiectantul documentului l-a avut în minte atunci când a creat Document Type Definition -ul. Într-un mediu care nu validează se pot crea etichete și atribute pe măsura înaintării. Foaia sau manualul de codare afișează toate acestea într-un format ușor de citit și înțeles, dacă autorul Document Type Definition -ului și-a făcut treaba corect. Când se creează un document “XML” sau se corectează o eroare, este posibil să nu se beneficieze de avantajul unui mediu de creare complet. Este întotdeauna importantă păstrarea la îndemână a documentației de codare pentru cazul în care apar defecțiuni.

CAPITOLUL II

Ce este LINQ

LINQ = Language Integrated Query și înseamnă “Limbaj integrat de interogare a datelor”.

Mai exact LINQ poate fi folosit pentru a interoga date din obiectele .NET care implementează interfața Ienumerable, din orice tip de bază de date relațională sau din fișiere “XML”.

Pentru interograrea obiectelor .NET Framework există LINQ to Objects, pentru bazele de date relaționale LINQ to ADO.NET și pentru documentele “XML”- LINQ to “XML”.

LINQ a apărut din nevoia de a umple golul care se găsea între un limbaj de programare orientat obiect și modul de acces la date (spre exemplu C# și ADO.NET), din dorința de a unifica modul de acces la date, de a-l face la fel de simplu că accesarea datelor dintr-o variabilă.

LINQ introduce conceptul de interogare direct în orice limbaj de programare din .NET Framework.

LINQ a apărut prima dată ca parte a limbajului de programare C# , aflat în stadiul de cercetare la Microsoft. Prima lansare comercială a LINQ a venit odată cu lansarea .NET Framework 3.5 și a Visual Studio 2008 în Noiembrie 2007.

În momentul de față se află în dezvoltare la Microsoft Research PLINQ a Parallel LINQ ca parte a proiectului Parallel FX Library.

LINQ este independent de limbaj. Există implementări LINQ și pentru : LINQ to JavaScript a implementat de Chris Pietschmann PHPLinq a implementat de Maarten Balliauw Quaere a implementare a LINQ sub Java GLinq a LINQ pentru accesul la date Google.

LINQ și C#

Pentru a putea folosi facilitățile LINQ în C# avem nevoie de următoarele assembly-uri care trebuie incluse în lista de referințe a proiectului:

System.Core.dll – Definieste nucleul LINQ API. Este obligatoriu pentru a putea folosi LINQ.

System.Data.Linq.dll – Lucrul cu baze de date relaționale (LINQ to SQL).

System.Data.DataSetExtensions.dll – O extensie care integrează tipurile ADO.NET cu LINQ (LINQ to DataSet)

System.”XML”.Linq.dll – Lucrul cu documentele “XML” (LINQ to “XML”)

În codul C# trebuie să includem directiva : using System.Linq; pentru a avea acces la tipurile de date definite de LINQ

Fundamente LINQ

Interogarea simplă:

Interogarea LINQ este foarte asemănătoare cu o interogare SQL. Operatorul from se folosește pentru a specifica sursa de date, where specifică condiția de filtrare, iar select selectează numele dezvoltatorului.

Interogările LINQ pot fi exprimate în două moduri: fie ca „query expressions” sau ca invocare explicită a metodelor utilizate.

Interogările LINQ:

Forma unei interogari LINQ este data de urmatoarele reguli :

query-expression ::= from-clause query-body

query-body ::=

join-clause*

(from-clause join-clause* | let-clause | where-clause)*

orderby-clause?

(select-clause | groupby-clause)

query-continuation?

from-clause ::= from itemName in srcExpr

select-clause ::= select selExpr

groupby-clause ::= group selExpr by keyExpr

let-clause ::= let itemName = selExpr

where-clause ::= where predExpr

join-clause ::=

join itemName in srcExpr on keyExpr equals keyExpr

(into itemName)?

orderby-clause ::= orderby (keyExpr (ascending | descending)?)*

query-continuation ::= into itemName query-body

CAPITOLUL III

ASP.NET introducere

O dată cu apariția framework-ului ASP.NET, Microsoft a încercat să implementeze modelul din windows forms în dezvoltarea de aplicații web. Pentru a simula experiența programatorului din modelul windows forms, au fost introduse în web forms programarea bazată pe evenimente, Viewstate (pentru a persista schimbările de stare între postback-uri) și Postback. Acestea au dus la încălcarea naturii fară stare (stateless) a aplicațiilor web. Ciclul de viață a unei pagini în acest model este complex și duce la o cuplare strânsă, având o singură clasă pentru a afișa interfața la client și pentru tratarea intrării de la utilizator.

ASP.NET MVC este o alternativă pentru ASP.NET și cele două variante vor co-exista. Ambele abordări țin de alegerea programatorului.

Ce este ASP.NET MVC?

Framework-ul ASP.NET MVC implementează șablonul arhitectural Model-View-Controller pentru dezvoltare de aplicații. Șablonul MVC a fost introdus inițial în anul 1979 de către Trygve Reenskaug care lucra la limbajul Smalltalk.

Principiul este de a împărții aplicația în trei părți distincte:

controllerul (primește și tratează intrarea),

modelul (conține logica aplicației) și

view-ul (generează ieșirea).

Controller-ul

Controller-ul este responsabil cu primirea cererilor de la client (din browser). Fiecare cerere în browser este mapată la o clasă controller. De exemplu, controller-ul poate returna la utilizator un view sau poate redirecta spre un alt controller.

Numele unei clase controller trebuie să se termine cu sufixul Controller. De exemplu:

TestController este corect, dar un controller cu numele Test nu va funcționa (va arunca excepție).

Un controller este o clasă ce trebuie să extindă clasa System.Web.Mvc.Controller.

Acțiunile unui controller

Un controller expune acțiuni. O acțiune este o metodă în clasa controller-ului care este apelată atunci când utilizatorul introduce un URL în bara de adrese a browser-ului.

O acțiune a controller-ului trebuie să fie o metodă publică. Trebuie avut în vedere faptul că orice metodă publică din clasa controller este automat expusă ca o acțiune a controller-ului. Astfel, poate fi apelată de oricine doar prin scrierea URL-ului corespunzător în bara de adrese a browser-ului.

Mai există și alte reguli ce trebuie respectate de o acțiune a controller-ului: o metodă folosită ca acțiune nu poate fi supraîncărcată și nu poate fi statică.

Ceea ce returnează o acțiune a unui controller reprezintă răspunsul cererii de la browser. Framework-ul ASP.NET MVC suportă sașe tipuri standard de rezultat:

1. ViewResult – Reprezintă “HTML”.

2. EmptyResult – Reprezintă nici un rezultat.

3. RedirectResult – Reprezintă o redirectare spre un alt URL.

4. RedirectToRouteResult – Reprezintă o redirectare spre o altă acțiune a controlerului.

5. JsonResult – Reprezintă un rezultat JavaScript Object Notation ce poate fi folosit intr-o aplicație AJAX.

6. ContentResult – Reprezintă un rezultat text.

Toate aceste clase ce pot fi returnate de o acțiune extind clasa de bază ActionResult. În cele mai multe cazuri, acțiunea controller-ului întoarce un ViewResult.

View-ul

Spre deosebire de ASP.NET sau ASP, în ASP.NET MVC nu este inclus ceva ce în mod direct corespunde unei pagini. Într-o aplicație ASP.NET MVC nu există o pagină pe disc ce corespunde căii din URL care a fost scrisă de utilizator în browser. Ceva apropiat de paginile din ASP.NET este în ASP.NET MVC un view. După cum a fost descris în secțiunea despre controller, o cerere din browser este mapată unui controller, care poate returna un view. Calea spre view este dedusă din numele controller-ului și numele acțiunii din controller. View-ul trebuie adăugat în directorul cu același nume ca și controller-ul care îl returnează (fără sufixul Controller).

Un view este un document standard (X)”HTML” ce poate conține script-uri.

Se poate folosi orice limbaj .NET pentru a genera conținut dinamic într-un view. De cele mai multe oriVisual Basic .NET sau C# vor fi folosite.

Pentru a fi mai ușor să se adauge conținut la un view, se poate folosi un, așa numit, “HTML” Helper. Un “HTML” helper este o metodă care returnează un string și poate fi folosit pentru a genera elemente “HTML” standard, cum ar textbox-uri, link-uri, dropdown-uri, etc.

Modelul

Modelul MVC conține logica aplicației ce nu ține de view sau de controller. În particular, modelul MVC conține logica business a aplicației și accesul la baza de date.

Pot fi folosite o varietate de tehnologii pentru a implementa logica de acces la baza de date, cum ar fi Microsoft Entity Framework, NHibernate, Subsonic, LINQ la SQL sau clase ADO.NET.

Anatomia unei aplicații ASP.NET

Aplicațiile ASP.NET sunt grupate în cadrul IIS în directoare virtuale. În acest fel directoarele fizice sunt expuse de către serverul Web pentru accesul din afară. În componența directorului aplicației pot intra mai multe fișiere și directoare.

De regulă o aplicație Web este compusă din următoarele ingrediente:

• Pagini Web: Reprezentate de fișierele cu extensia .aspx și definesc interfața Web a aplicației;

• Servicii Web: Module ce oferă funcții utile aplicațiilor (nu numaiWeb) aflate pe alte calculatoare și pe diferite platforme. Aceste module sunt reprezentate de fișiere cu extensia .asmx;

• Fișiere de cod: De obicei o pagina Web este însoțită de un fișier de cod ce conține logica aplicației pentru pagina respectivă. În funcție de modul de separare a codului de interfață pot exista mai multe fișiere sursă. De obicei numele fișierului sursă este dat de cel al paginii Web prefixat de extensia tipului de cod sursă (.cs sau .vb). De exemplu pentru pagina default.aspx avem fișierul sursă (C#) default.aspx.cs. Fișierul sursă poate fi schimbat prin setarea atributului CodeFile din directiva @Page, element aflat în antetul unei pagini ASP.NET;

• Un fișier de configurare numit web.config în care sunt păstrate opțiunile pentru grupul de pagini Web conținute în directorul curent și subdirectoarele acestuia. Pot exista mai multe fișiere web.config în fiecare subdirector. La nivelul sistemului setările din toate fișierele web.config sunt văzute unitar. O pagină Web poate accesa toate proprietățile din fișierele web.config aflate în directorul curent și din toate directoarele ce compun calea către aceasta;

• Fișierul Global.asax: Conține funcțiile de tratare a evenimentelor globale ale aplicației (lansarea aplicației, cereri, etc.)

• Alte componente necesare compunerii aplicației. De obicei acestea sunt assembly-uri, imagini, CSS-uri, etc.

În legătură cu fișierul Global.asax trebuie făcute câteva precizări.

După cum am spus mai sus acest fișier permite scrierea codului de tratare pentru evenimentelor globale. Deși clienții site-ului nu accesează niciodată acest fișier, codul din acesta (sau din fișierul de code behind asociat) se execută ca răspuns la anumite evenimente. Începând cu ASP.NET 2.0 structura de directoare recunoscute automat s-a extins.

Avantaje ASP.NET MVC

Controlul integral asupra “HTML”–ului redat.

Separarea conceptelor (separation of concerns SoC).

Folosirea cu ușurința a programării bazată pe teste (Test Driven Development – TDD).

Respectarea designului fără stare a web-ului.

Include o componentă de mapare a URL-urilor pentru crearea de aplicații cu URL-uri simple,permițând optimizarea pentru motoarele de căutare (SEO).

Suportă motoare de vizualizare cum ar fi NVelocity, Brail, NHaml.

Nu folosește modelul existent în web forms de post–back pentru interacțiunea cu serverul.Acest model a fost înlocuit cu direcționarea interacțiunii utilizatorului la o clasă Controller,astfel se realizează separarea conceptelor și ușurința testării.

Framework extensibil. Framework MVC este proiectat pentru a fi ușor de înlocuit șipersonalizat (de exemplu este posibil ca un alt motor de vizualizare să fie conectat sau regulilede rutare să fie personalizate). De asemenea suportă injectare de dependențe (dependecyinjection) și modele de containere IOC (Windsor, Spring.Net, NHibernate, etc) .

Concluzii

Pentru programatorii care doresc să creeze aplicații folosind arhitectura MVC, framework ASP.NET MVC este o opțiune ușoară și curată. Oferă posibilitatea de a menține ușor separarea conceptelor în aplicație, de asemenea, facilitatea de a crea unit teste și de a aborda programarea bazată pe teste.

CAPITOLUL IV

Ce este SOA:

SOA este o abordare în dezvoltarea aplicațiilor software pentru organizații, în așa fel încât procesele software sunt separate în servicii care sunt făcute apoi disponibile și pot fi găsite în cadrul unei rețele. Fiecare serviciu oferă funcționalități care pot fi adaptate la nevoile unei organizații, ascunzând detaliile referitoare la dedesubturile implementării. SOA se adresează complexității, inflexibilității si slăbiciunilor abordărilor existențe din proiectarea proceselor, a fluxurilor de lucru și a integrării aplicațiilor.

Adesea serviciile invocate sunt ierarhizate, așa cum arată figură de mai jos:

SOA (Service Oriented Architecture) este în primul rând un concept. Nevoia acestui concept a apărut în încercarea de a acoperi acea diferență dintre cerințele zonei de business și capabilitățile zonei de IT. Puntea se realizează printr-un set de servicii IT aliniate cu cerințele de business, utilizând un set de principii, tehnici și modele de proiectare. Implementarea se regăsește în tools-uri informatice, dar acestea sunt secundare. SOA este un element care asigură apariția inovației. Dar nu a inovației tehnologice, ci a inovației în zona de business, care să asigure avantajul competitiv. De fapt, ce este acest avantaj competitiv? Ceva mai simplu decât mulți se așteaptă. Avantajul competitiv este dificultatea majoră pe care o întâmpina competiția de a copia un model care și-a arătat eficiența, care a penetrat piața și a generat o nouă nevoie. Nevoile pieței sunt intrinseci, în stare dormanda. Acea inovație care este declanșatorul conștientizării nevoii de către piață și care îi poate da un răspuns rapid, asigură avantajul competitiv.

Nevoia de SOA

Implementarea corecta a principiilor SOA asigura:

Eficienta prin flexibilitate, prin automatizare și integrarea proceselor de business

Reducerea costurilor prin reutilizare a ce s-a dezvoltat mai inainte și nu prin reinventarea și dezvoltarea de la zero pentru fiecare nou produs sau canal de distributie

Descresterea timpilor de time-to-market și time-to-yes prin standardizare și reutilizarea serviciilor precedent dezvoltate

Simplificarea infrastructurii și complexitatii IT a companiei, posibilitatea aplicarii unor principii de arhitectura bine fundamentate

Sustinerea inovatiei de business și a avantajului competitiv.

Conform Gartner, SOA va fi diferentiatorul competitiv cheie, nefinanciar, pentru majoritatea băncilor din lume. și această deoarece va permite componentelor software dintr-o rețea să fie utilizate, reutilizate și, la fel de important, va permite datelor să fie reutilizate de diferite componente cheie.

Beneficii ale SOA

SOA poate să ușureze integrarea diverselor medii care sa găsesc în multe organizații. SOA facilitează colaborarea și distribuirea de informații în cadrul întregii organizații și cu partenerii externi. Prin expunerea proceselor de business, SOA vă ajută să vă concentrați asupra celor mai bune metode de a va îmbunătăți operațiunile. SOA vă furnizează capacitatea de a susține un model de afacere care depășește granițele organizației. SOA îmbunătățește

colaborearea, facilitează procesele de afaceri complete și îmbunătățește eficacitatea operațională.

SOA vă permite să vă customizati procesele de afaceri, fără să modificați codul sursă. Cu SOA, să faceți procesele din cadrul sistemului să se portiveasca cu afacerea dvs este o problemă de configurare, nu de customizare. Această înseamnă că atunci când este momentul să faceți update-ul cu o nouă versiune, puteți să faceți acest lucru mult mai ușor decât în cazul în care ați fi avut customizari răzlețe în cadrul implementării.

Un alt beneficiu al SOA este faptul că va furniza abilitatea de a simplifica procesele de afaceri, care, la rândul lor, promovează un management agil al proceselor de afaceri. SOA vă pune la dispoziție o posibilitate de a face procesele de afaceri mai transparente, astfel încât să poată fi customizate și optimizate, pentru a veni mai bine în întâmpinarea cererilor de la clienți pentru timpi de răspuns mai reduși, păstrând în același timp o calitate ridicată și credibilitate. Și, poate cel mai important, SOA păstrează complexitatea unei integrări application-to-application și business-to-business, reducând semnificativ costurile și ridicând tehnologia la nivel de afacere.

Proprietăți ale implementarii SOA

Servicii – compente ce pot fi refolosite și reprezinta taskuri business:

Influenta folosirii arhitecturii SOA asupra Serviciilor:

Serviciile și Costul scazut

Serviciile și Agilitatea

Serviciile și Adaptabilitatea

SOA oferă arhitectură completă pentru un system, Un pattern arhitectural oferă ghidaj a elementele concrete și interacțiunea lor . Reprezintă arhitectura sistemului.SOA nu poate fi cumpărat incluzând calitatea sistemului (care trebuie construită pe arhitectura sistemului), deciziile care trebuie luate(design-ul pentru servicii, implementarea, tehnologiile)

Ciclul de viață SOA

SOA poate fi abordata gradual, ca cicluri de viață (life cycle). In primul stadiu se modeleaza, se schiteaza cerințele de business și se intemeiaza procesele aferente. Urmatoarea etapa este de asamblare a serviciilor existente cu unele noi pentru a forma procesele. Etapa implementarii acestora într-un mod securizat și integrat, este urmatoarea. Aceste informații adunate ne vor oferi date ajutatoare la îmbunătățirea acestor procese.

Implementare

Conform[1] „Pe durata etapei de implementare, este dezvoltat un mediu integrat și securizat în care serviciile specializate asigură interacțiunea dintre oameni, procese și informații. La acest nivel, se urmărește schimbul de informații în sistem, funcționarea optimă a aplicațiilor, modul de finalizare al oricărei acțiuni și derularea eficientă a proceselor:

configurarea unui mediu IT pentru asigurarea unui nivel de suport necesar fiecărui proces

optimizarea mediului IT pentru susținerea proceselor critice

reducerea complexității prin păstrarea unui nivel de integrare point-to-point „

Administrare

După implementare, funcționalitatea unei Arhitecturi Orientate către Servicii trebuie monitorizată atât din perspectiva de business cât și din perspectiva IT. Informațiile adunate în această etapă, pe baza indicatorilor de performanță, oferă o privire real-time asupra proceselor și implicit un feed back continuu pentru îmbunătățirea acestora, precum și un suport decizional îmbunătățit.:

identificarea și păstrarea ratelor de diponibilitate a serviciilor și a timpului de răspuns

monitorizarea, real-time, a indicilor de performanță (key performance indicators-KPIs)

prevenirea, izolarea, diagnosticarea și rezolvarea problemelor

oferirea unui feed back real și vital pentru îmbunătățirea proceselor

CAPITOLUL V

Limbajul de programare C# și trăsăturile lui

Principalele trăsături ale limbajului de programare C# sunt:

este un limbaj de programare orientat pe obiecte, simplu, modern, derivat din C++ și Java;

scopul lui este de a combina "Testivitatea" mare a limbajului Visual Basic și puterea brută a limbajului C++;

face parte din pachetul Microsoft Visual Studio 7.0;

versiunea Visual Studio suporta Vb, VC++, C++, Vbscript, Jscript; toate aceste limbaje au prevazut accesul la platforma Microsoft .NET;

platforma .NET include un motor Common Execution, precum și o biblioteca bogata de clase;

echivalentul Microsoft pentru Masina Virtuala Java este Common Language run time (CLR);

CLR gazduieste mai mult de un limbaj de felul C#, VB.NET, Jscript, ASP.NET, C++;

codul sursa este transformat în cod în limbaj intermediar (Intermediate Language code IL), care este transformat în cele din urma în cod nativ (JIT Compiler);

tipurile de date și clasele sunt comune pentru toate limbajele .NET;

în C# se pot dezvolta aplicatii pentru consola (Console application), aplicatii pentru Windows (Windows application), aplicatii pentru Web;

în limbajul C#, Microsoft s-a îngrijit de probleme ca: management-ul memoriei, pointeri;

este prevazut cu facilitati de "garbage collection", management automat al memoriei și altele.

Urmatoarele sase trasaturi caracterizeaza limbajul C#:

este simplu,

este modern,

este orientat pe obiecte,

este type safe,

este interoperabil,

este scalabil și

poate fi adus la zi (updated).

Simplitate:

În C# nu exista pointeri.

Operatii nesigure cum ar fi manipularea directa a memoriei nu sunt permise.

În C# nu sunt folositi operatorii "::" și "->".

Întrucât este integrat pe platforma .NET, "mosteneste" facilitatile de "garbage collection" și management-ul automat al memoriei.

Ofera intervale variabile pentru tipurile primitive ca Integer, Float.

Valorile întregi 0 și 1 nu mai sunt acceptate ca și valori Booleene. Aceste valori Booleene sunt pur și simplu true și false în C#, astfel ca nu vor mai aparea erori la folosirea operatorului "=" și a operatorului "=="; în C# operatorul "==" este folosit doar pentru operatia de comparatie, iar operatorul "=" doar pentru operatia de atribuire.

Modernitate:

C# a fost scris în acord cu tendintele actuale, fiind un foarte puternic și simplu limbaj de programare pentru construirea unor aplicatii interoperabile, scalabile și robuste.

C# include suport "built in" pentru a transforma orice componenta într-un serviciu web, care sa poata fi accesat pe Internet de orice fel de aplicatie care ruleaza pe orice fel de platforma.

Orientat pe obiecte:

C# suporta încapsularea datelor, mostenirea, polimorfismul și interfetele.

În Java, "int, float și double" nu sunt obiecte, dar C# a introdus structurile (structs) care permit tipurilor primitive sa devina obiecte:
int i=1;
String a=i Tostring();//conversie sau Boxing

Type safe:

În C# nu este permis sa se execute cast-uri nesigure, cum ar fi convertirea unei variabile double în variabila Booleana.

Tipurile primitive sunt initializate cu zero și tipurile de referinta (obiecte și clase) sunt initializate cu null de catre compilator automat.

Tablourile sunt neindexate și sunt verificate.

Depasirea tipurilor poate fi verificata.

Interoperabilitate:

C# include suport pentru COM și pentru aplicatii bazate pe ferestre.

Permite uzul pointerilor, dar cu restrictii.

Programatorul nu mai trebuie sa implementeze explicit interfetele unknown și COM; aceste trasaturi sunt "bilt in".

C# permite programatorilor sa foloseasca pointerii ca "unsafe code blocks" pentru a manipula codul vechi.

Componente din VB.NET și din alte limbaje pot fi folosite direct în C#.

Scalabilitate și update:

Platforma .NET a introdus ansamble (assemblies) care sunt auto-descrise de felul lor de manifestare. Felul de manifestare stabileste identitatea ansamblului, versiunea și semnatura digitala. Aceste ansamble nu trebuie sa fie înregistrate niciunde.

Pentru a scala aplicatia, programatorul trebuie sa stearga fisierele vechi și sa le aduca la zi (update) cu cele noi. Nu trebuie înregistrate DLL-urile (dynamic link libraries).

Aducerea la zi (update) a componentelor software este o sarcina (task) predispusa la erori; revizuirea codului poate afecta versiunea suportului programului C# în limbaj.

Suportul oferit pentru interfete și redefinirea metodelor face posibil ca aplicatiile complexe cu frame-uri sa fie elaborate și dezvoltate de-a lungul timpului.

In concluzie C# este un limbaj de programare simplu, modern, "type safe", orientat pe obiecte, care permite programatorilor sa construiasca usor și rapid solutii pentru platforma Microsoft .NET.

Despre limbajul C# și platforma .NET

În strânsă legatură cu Arhitectura .NET (.NET Framework) pe care funcționează, C# gestionează în mod automat memoria utilizată. Eliberarea memoriei ocupate (garbage collection) de către obiectele care nu mai sunt necesare aplicației, este o facilitate importantă a limbajului. Programatorii nu mai trebuie să decidă singuri, așa cum o fac de pildă în C++, care este locul și momentul în care obiectele trebuie distruse.

Arhitectura .NETeste o componentă software care oferă un mediu de programare și de execuție a aplicațiilor pentru sistemele de operare Microsoft. Este inclusă în sistemele de operare Windows Server 2008și Windows Vista și poate fi instalată pe Windows XPși Windows Server 2003.

.NET Framework este un mediu care permite dezvoltarea și rularea aplicațiilor și a serviciilor Web,independente de platformă.

Limbajul C# se află într-o strânsă legatură cu arhitectura .NET. Inițial, C# a fost dezvoltat de către Microsoft pentru crearea codului platformei .Net, la fel cum destinația inițială a limbajului C a fost aceea de a implementa sistemul de operare UNIX. .NET pune la dispoziție o colecție impresionantă de clase organizate în biblioteci, pecare C# le utilizează.

Este momentul să precizăm că C# funcționează având .NET ca infrastructură, dar .NET suportă și altelimbaje, cum este C++, Visual Basic sau Java. În oricare dintre aceste limbaje programați, aveți la dispoziție aceleași biblioteci de clase. .NET se realizează în acest fel interoperabilitatea limbajelor.

CAPITOLUL VI

Prezentarea generală a limbajului SQL

SQL (Structured Query Language) este în prezent, unul din cele mai puternice limbaje structurate pentru interogarea bazelor de date relaționale.

Este un limbaj neprocedural și declarativ, deoarece utilizatorul descrie ce date vrea să obțină, fără a fi nevoie să stabilească modalitățile de a ajunge la datele respective. Nu poate fi considerat un limbaj de programare sau unul de sistem, ci mai degrabă face parte din categoria limbajelor de aplicații, fiind orientat pe mulțimi. Foarte frecvent, este utilizat în administrarea bazelor de date client/server, aplicația client fiind cea care generează instrucțiunile SQL.

Lansat inițial de IBM. Standardizat prima dată de ANSI, apoi ISO. Actualmente, ISO 92. Pentru că există o standardizare a limbajului SQL, multe SGBD (Oracle, Access, Sybase) recunosc principalele instrucțiuni ale acestuia.

Caracteristicile adăugate standardului se numesc extensii. De ex, în standard sunt specificate 6 tipuri diferite de date pentru o BD SQL. În multe implementări, această listă este completată cu o diversitate de extensii. Fiecare implementare se numește dialect. Dialectul ACCSES conține unele particularități, fiind conceput mai mult pentru crearea interogărilor de selecție.

Există 3 metode de bază privind implementarea limbajului SQL:

apelare directă (Direct Invocation): constă în introducerea instrucțiunilor direct de la prompter

modulară (Modul Language): folosește proceduri apelate de programele aplicație

încapsulată (Embedded SQL): conține instrucțiuni încapsulate în codul de program

Instrucțiunile SQL pot fi grupate în:

instrucțiuni de definire a datelor, care permit descrierea structurii BD

instrucțiuni de manipulate a datelor: adaugă, șterge, modifică înregistrări

instrucțiuni de selecție a datelor, care permit consultarea BD

instrucțiuni de procesare a tranzacțiilor

instrucțiuni de control al cursorului

instrucțiuni pivind controlul accesului la date

În limbajul SQL standardizat de ISO nu se folosesc termenii formali de relație, atribut, tuplu, ci tabel, coloană, rând.

Scrierea comenzilor SQL

O instrucțiuni SQL este formată din cuvinte rezervate și cuvinte definite de utilizator. Cuvintele rezervate constituie partea fixă și se scriu exact cum este necesar. Cuvintele definite de utilizator reprezintă denumirile diverselor obiecte din BD.

Deși standardul nu o cere, majoritatea dialectelor cer terminator de instrucțiune („;”).

Majoritatea componentelor nu sunt sensibile la tipul de litere (excepție importantă: când datele au caracter literal, de ex, dacă se stochează numele „MAMA” și cautăm „Mama”, nu vom găsi înregistrarea respectivă).

Deși SQL este un limbaj cu format liber, o instrucțiune este mai lizibilă dacă se utilizează indentarea și alinierea. De exemplu:

• fiecare clauză dintr-o instrucțiune trebuie să înceapă pe o linie nouă

• începutul fiecărei clauze să fie aliniat cu începutul celorlalte

• dacă o clauză are mai multe părți, fiecare parte trebuie să apară pe câte o linie separată și trebuie indentată față de începutul clauzei

Convenții de notare folosite în definirea instrucțiunilor:

• majuscule pentru cuvintele rezervate

• litere mici pentru cuvinte definite de utilizator

• bara verticală | indică posibilitatea alegerii dintre mai multe variante

• acoladele { } indică un element necesar

• parantezele drepte [ ] indică un element opțional

• punctele de suspensie … indică o repetare opțională a unui articol, de 0 sau mai multe ori

Identificatorii SQL sunt utilizați pentru a numi obiecte din BD. Pentru caracterele utilizate, standardul ISO permite A…Z, a…z, 0…9, _. Restricții impuse identificatorilor:

• nu poate fi mai lung de 128 caractere (majoritatea dialectelor au o limită mult mai joasă)

• trebuie să înceapă cu o literă

• nu poate conține spații libere

Instrucțiuni pentru definirea datelor

Teoretic, comenzile pentru definirea datelor fac parte din modulul corespunzător componentei DDL din SGBD. Totuși, în majoritatea implementărilor SQL comenzile de definire a datelor sunt prelucrate de același interpretor care rezolvă și interogările și operațiile de manipulare a datelor. Componentele DML și DDL ale SGBD sunt implementate în același modul software.

CREATE DATABASE nume_bd:crează o bază de date. Majoritatea SGBD permit crearea unei BD print-un simplu clic de mouse. Există și posibilitatea folosirii acestei instrucțiuni, dar mult mai greoi. Comanda nu e standardizată, ACCESS nici nu o acceptă.

CREATE TABLE numele_tabelei

(câmp1 tipul_datei [NOT NULL],

câmp2 tipul_datei [NOT NULL],

câmp3 tipul_datei [NOT NULL]…) :crează un tabel și definește structura unei înregistrări precum și tipurile de date asociate câmpurilor. Numele tabelului trebuie să fie unic în BD. Clauza NOT NULL arată că în câmpul respectiv nu se memorează valori de tip NULL.

ALTER TABLE numele_tabelei

ADD numele_câmpului tipul_datei : adaugă un câmp la un tabel existent. Ștergerea unui câmp nu este posibilă.

DROP TABLE numele_tabelei :sterge complet un tabel din BD.

DROP DATABASE nume_bd :șterge BD. Există însă o multitudine de restricții stabilite de administratorul sistemului privind această operație. Multe versiuni SQL nu includ această instrucțiune, stregerea făcându-se din comenzi de mouse.

Instrucțiuni pentru selecția datelor

Cereri de interogare simple

Instrucțiunile de selecție reprezintă una din categoriile cele mai importante ale limbajului SQL ACCESS. Indiferent dacă sunt cereri simple sau complexe, cuvântul cheie este SELECT. Pentru cererile de interogare simple, sintaxa instrucțiunii este:

SELECT [domeniu] listă_select

FROM numele_tabelei1, numele_tabelei2,…

[WHERE criteriu_selecție]

[ORDER BY câmpuri_criteriu [ASC|DESC]];

Domeniu: specifică o opțiune de includere sau eliminare din rezultatul selecției, a înregistrărilor care conțin duplicate. Opțiunile posibile sunt:

ALL cere includerea tuturor înregistrărilor care îndeplinesc condițiile impuse. Cum instrucțiunile SELECT tabel și SELECT ALL tabel au același rezultat practic, calificativul ALL este rar folosit.

DISTINCT cere eliminarea înregistrărilor care conțin duplicate în câmpurile selectate, afișând numai o apariție a acesteia.

DISTINCTROW cere eliminarea înregistrărilor care conțin duplicate în ansamblul lor, nu numai în câmpurile selectate, afișând numai o apariție a acesteia.

Listă_select cuprinde câmpurile care dorim să apară în tabelul cu rezultatele interogării. Similar cu Field … Show …din grila de proiectare QBE.

Clauza FROM specifică numele tabelului sau tabelelor pe care se face cererea de interogare. Pentru mai multe tabele, numele acestora se separă cu „,”. Pe lângă tabele, ca sursă de informații pot apare și interogări deja create.

Clauza WHERE cere numai înregistrările care îndeplinesc criteriul de selecție specificat. Criteriul de selecție este o expresie care conține obligatoriu și un operator adecvat tipului de dată al câmpului respectiv. Clauza WHERE este opțională.

Clauza ORDER BY cere ordonarea în mod crescător (ASC) sau descrescător (DESC) a rezultatelor interogării. Ordonarea este opțională și se poate face după unul sau mai multe câmpuri_criteriu.

Cereri de interogare complexe : sunt acele interogări în care apar funcțiile agregat, asocierile sau combinările.

Funcțiile agregat

Permit construirea unor interogări complexe, prin care utilizatorul cere gruparea înregistrărilor care au câmpuri cu aceeași valoare, în scopul efectuării unor calcule. În standardul ISO sunt definite 5 funcții de grup:

COUNT returnează numărul de valori dintr-o coloană specificată

SUM returnează suma valorilor dintr-o coloană specificată

AVG returnează media valorilor dintr-o coloană specificată

MIN returnează cea mai mică valoare dintr-o coloană specificată

MAX returnează cea mai mare valoare dintr-o coloană specificată

Sintaxa instrucțiunii:

SELECT [domeniu] funcție_agregat(numele_câmpului) AS alias [,listă_select]

FROM numele_tabelei1, numele_tabelei2,…

GROUP BY câmp_de_grupare

[HAVING criteriu_de_grupare]

[ORDER BY câmpuri_criteriu [ASC|DESC]];

Elementele noi de sintaxă:

AS alias asociază un pseudonim rezultatului funcției agregat

Clauza GROUP BY precizează câmpul sau câmpurile după care se face gruparea înregistrărilor. Echivalentul acestei clauze în macheta grafică QBE îl reprezintă rândul Total.

Clauza HAVING conține criteriul care va fi aplicat câmpului argument al funcției agregat. Spre deosebire de WHERE, care acționează înainte de gruparea înregistrărilor, HAVING acționează după definirea acesteia.

Asocierile ( JOIN)

Limbajul SQL oferă posibilitatea de a grupa și folosi date din tabele diferite. Operațiile de asociere induse de clauza JOIN au ca rezultat producerea tuturor combinațiilor posibile, pentru conținutul informațional al fiecărui tabel. Noile înregistrări care rezultă în urma joncțiunii sunt disponibile pentru selecțiile următoare. La o asociere pot participa mai mult de 2 tabele.

Există mai multe categorii de joncțiuni:

CROSS (încrucișată) – rar folosită

ECHIVALENTĂ (echijoncțiune) – cea mai folosită – presupune folosirea clauzei WHERE asociată cu o egalitate dorită

NEECHIVALENTĂ (non echijoncțiune) – rar folosită – presupune folosirea clauzei WHERE asociată cu orice alt operator de comparare, în afară de „=”

Sintaxa instrucțiunii pentru joncțiunile echivalente și neechivlente este:

SELECT [domeniu] listă_select

FROM numele_tabelei1, numele_tabelei2,…

[WHERE criteriu_de_asociere]

[ORDER BY câmpuri_criteriu [ASC|DESC]];

Deoarece în instrucțiunile SQL care descriu joncțiuni se utilizează câmpuri care fac parte din tabele diferite, trebuie specificat numele tabelului de care aparțin, folosind sintaxa: numele_tabelei.numele_câmpului fără spații înainte sau după punct.

După modul de asociere a înregistrărilor din tabele, joncțiunile pot fi:

interne sau INNER JOIN determină o asociere a înregistrărilor din tabele, astfel încât să rezulte un număr total de înregistrări egal cu produsul numărului de înregistrări din fiecare tabel

externe de stânga sau LEFT OUTER JOIN

externe de dreapta sau RIGHT OUTER JOIN

Echivalentul QBE al acestor categorii de joncțiuni este alegerea opțiunilor 1, 2, sau 3 din caseta Join Properties.

Sintaxa instrucțiunii:

SELECT [domeniu] listă_select

FROM numele_tabelei1

{INNER|LEFT OUTER|RIGHT OUTER} JOIN numele_tabelei2

ON criteriu_de_asociere

[{INNER|LEFT OUTER|RIGHT OUTER} JOIN numele_tabelei3

ON criteriu_de_asociere]…

[WHERE criteriu_selecție]

[ORDER BY câmpuri_criteriu [ASC|DESC]];

Obs: SQL ACCESS acceptă scrierea fără specificarea explicită a lui OUTER.

Semnificația elementelor noi:

JOIN specifică tabelul care va fi asociat (numele_tabelei2, numele_tabelei3) celui din clauza FROM

ON arată între ce câmpuri trebuie să existe relația pe care se bazează joncțiunea. Criteriul de asociere conține obligatoriu operatorul „=”.

Combinările (UNION)

Când utilizatorul dorește să vadă rezultatele mai multor interogări SELECT în același timp, prin combinarea ieșirilor lor, se poate utiliza facilitatea UNION. De remarcat că nu există echivalent QBE pentru această instrucțiune.

Sintaxa generală pentru interogările UNION este:

SELECT listă_câmpuri FROM numele_tabelei1

UNION SELECT listă_câmpuri FROM numele_tabelei2

[GROUP BY câmp_de_grupare]

[HAVING criteriu_de_agregare]

[UNION SELECT listă_câmpuri FROM numele_tabelei3

[GROUP BY câmp_de_grupare]

[HAVING criteriu_de_agregare]]

[UNION …]

[ORDER BY câmpuri_criteriu [ASC|DESC]];

Există mai multe restricții pentru instrucțiunile care genereză interogările UNION, și anume:

Numărul câmpurilor din lista de câmpuri din fiecare instrucțiune SELECT și UNION SELECT trebuie să fie aceeași

Secvența de nume din fiecare listă de câmpuri trebuie să corespundă unor intrări identice

Este permisă utilizarea doar o dată a clauzei ORDER BY, după ultima instrucțiune UNION SELECT

Instrucțiuni pentru manipularea datelor

Foarte utile în exploatarea unei BD, aceste instrucțiuni se implementează prin interogările de acțiune. Este necesară o mare precauție în utilizarea lor deoarece acțiunile sunt ireversibile, putând influiența inclusiv integritatea referențială a BD.

Cele mai importante sunt: CREATE, INSERT, UPDATE și DELETE.

Interogările de acțiune tip CREATE duc la generarea unui nou tabel pornind de la structura și conținutul unor tabele deja existente. Se folosește instrucțiunea

SELECT … INTO

SELECT [domeniu] (câmp1,câmp2…)

INTO tabel_nou

FROM tabel_sursa

[WHERE criteriu_de_adăugare];

Interogările de acțiune tip INSERT sunt folosite pentru adăugarea de înregistrări dintr-un tabel în altul. Există două forme ale instrucțiunii și anume:

INSERT … VALUES

INSERT … SELECT

In primul caz se adaugă o singură înregistrare într-un tabel, menționându-se câmpurile și valorile acestora. Se utilizează pentru operații simple, care presupun lucrul cu un număr redus de înregistrări.

INSERT INTO numele_tabelei (câmp1, câmp2…)

VALUES (valoare1, valoare2…);

Reguli:

valorile din clauza VALUES vor avea aceeași natură cu câmpurile din clauza INTO

mărimea valorii va fi < dimensiunea câmpului

corespondență între câmp1 și valoare1, etc.

Dacă un câmp are specificația NOT NULL, este obligatorie introducerea unei valori pentru aceasta

În al doile caz, este posibil să se copieze mai multe înregistrări dintr-un tabel în unul sau mai multe tabele.

INSERT INTO tabel_destinație (câmp1, câmp2…)

SELECT [domeniu] câmp1, câmp2…

FROM tabel_sursă

WHERE criteriu_de_adăugare;

Reguli:

• aceleași ca mai sus

• numărul și natura câmpurilor din clauza INTO să fie aceleași cu cele returnate de instrucțiunea SELECT

• dacă nu se introduce WHERE, toate înregistrările din tab_sursă vor fi adăugate în tab_destinație

Interogările de acțiune tip DELETE șterg parțial sau total înregistrările dintr-un tabel. Nu se folosește pentru ștergerea de valori din câmpuri individuale, ci acționează asupra înregistrării în totalitatea ei. Dacă se șterg toate înregistrările, structura de tabel rămâne, ea putând fi eliminată numai cu DROP TABLE.

DELETE FROM numele_tabelei

[WHERE criteriu_de_ștergere];

Ca și instrucțiunea INSERT, operația de ștergere a înregistrărilor dintr-o tabelă poate duce la probleme de integritate referențială în alte tabele.

Interogările de acțiune tip UPDATE pot introduce înregistrări noi și pot modifica valorile câmpurilor din înregistrări existente.

UPDATE numele_tabelei

SET numele_câmpului1=valoare1 [,numele_câmpului2=valoare2]…

[WHERE criteriu_de_actualizare];

Ca și în celelalte locuri unde apare clauza WHERE, restricționarea se poate accentua folosind și operatori logici.

Cereri de interogare imbricate

Scrierea unei interogări în cadrul alteia duce la apariția unei subinterogări, setul de rezultate obținute de la aceasta constituind argument pentru prima interogare.

SELECT lista_câmpuri

FROM tabel1

WHERE tabel1.numele_câmpului=

(SELECT numele_câmpului

FROM tabel2

WHERE criteriu_de_selecție);

Cele două tabele trebuie să aibă un câmp comun (numele_câmpului) care va reprezenta câmpul de legătură ce stă la baza construirii subinterogării.

CAPITOLUL VII

Aplicatie practica – descriere

Entity Framework și Linq cu aplicatii in baze de date medicale exploatate in regim SaaS

PRECIZARE : aplicatia reprezinta un caz particular al abordarii din teza.

Este o aplicatie destinata informatizarii activitatii cabinetelor medicilor.

Cu ajutorul aplicatiei , medicul / asistenta poate efectua :

Vizualizare lista pacienti inscrisi cu problemele medicale ale fiecarui pacient

Vizualizare vizitele pe care pacientul le-a efectuat la medic in legatura cu problemele sale medicale cum se vede in imaginea de mai jos:

Editare și adaugare grupa boli / boala/ cod boala cum se observa mai jos:

Introducere pacient nou : nume, care este și utilizatorul, prenume , CNP care este și parola , grupa de boala și boala , definite anterior :

La aplicatie se pot conecta trei tipuri de utilizatori : administratori, medici/asistente și pacienti. Administratorul poate adauga utilizatori noi dupa cum urmeaza :

Medic/ asistenta – care pot introduce grupe noi de boli, boli și coduri aferente acestora ; de asemenea pot adauga pacienti noi cu boala și grupa de boala respectiva .

Pacienti – care au acces la un PDF in care se regasesc datele introduse de catre personalul medical:

Alti administratori .

Cu ocazia realizării aplicatiei am aprofundat și mai mult studiul în tehnologiile:

“XML”;

LINQ;

ASP.NET;

SOA;

C#;

SQL;

Concluzie

Pentru mine redactarea licenței a fost un proces de sistematizare a lucrurilor studiate in cadrul facultatii. Din acest motiv consider că întregul proiect, din faza inițială, până la faza de documentare pentru redactarea licenței și scrierea propriu-zisă, a fost o ocazie de a avansa pe plan profesional. Aplicatia este accesibila și are un design minimalist și este usor de folosit (user-friendly).

Bibliografie:

„Peter Buneman, Susan Davidson, Gerd Hillebrand, Dan Suciu, A Query Language and Optimization Techniques for Unstructured Data, Proceedings of ACM-SIGMOD International Conference on Management of Data, Montreal, Canada,June, 1996, pages 505-516”

„S. Abiteboul, D. Quass, J. McHugh, J. Widom, J. Weiner, The lorel query language for semistructured data, Journal of Digital Libraries,Vol 1 number 1, 1997”

„L. V. S. Lakshmanan, F. Sadri, I. N. Subramanian,A declarative language for querying and restructuring the world-wide-web, Post-ICDE IEEE Workshop on Research Issues in Data Engineering (RIDE-NDS'96),New Orleans, February,1996”

„ A. O. Mendelzon, G. A. Mihaila, T. Milo, Querying the world Wide Web, Proc. PIDS '96, December, 1996”

„M. P. Consens, A. O. Mendelzon, Expressing Structural Hypertext Queries in Graphlog, Proc. 2nd ACM Conference on Hypertext, Pittsburgh, November, 1989”

„S. Cluet, G. Moerkotte, Query processing in the schemaless and semistructured context, INRIA, 1997”

„Mary Fernandez, Daniela Florescu, Jaewoo Kang, Alon Levy, Dan Suciu, STRUDEL: A Web Site Management System, Proc. of the 16th ACM SIGMOD Symposium on Principles of Database Systems,Tucson, Arizona, May, 1997”

„Sudarshan Chawathe, Hector Garcia-Molina, Joachim Hammer, Kelly Ireland, Yannis Papakonstantinou, Jeffrey Ullman, Jennifer Widom, The {TSIMMIS} Project:{Integration} of Heterogenous Information Sources, October, 1994, Tokyo, Japan, Proceedings of the Information Processing Society of Japan Conference
Yannis Papakonstantinou, Hector Garcia-Molina, Jennifer Widom, Object Exchange Across Heterogenous Information Sources, Proceedings of IEEE International Conference on Data Engineering, March, 1995, 251-260
J. McHugh, S. Abiteboul, R. Goldman, D. Quass and J. Widom, Lore: A database management system for semistructured data, Stanford University Database Group, February,1997”

„S. Abiteboul, D. Quass, J. McHugh, J. Widom, J. Weiner,The lorel query language for semistructured data,Journal of Digital Libraries,Vol 1 number 1, 1997”

„A. Levy, A. Rajaraman, J. J. Ordille, Querying Heterogeneous Information Sources Using Source Descriptions ,Proc. 22nd International Conference on VLDB, Mumbai, India, 1996”

„Arbor Software, Multidimensional Analysis: Converting Corporate Data into Strategic Information,White Paper J. Xenakis, editor, Mutlidimensional Databases, Application Development Strategies, April, 1994”

„J. Gray, A. Bosworth, A. Layman, H. Pirahesh, Data Cube: A Relational aggregation Operator Generalizing Group-By, Cross-Tab and Sub-Totals, Microsoft, MSR-TR-95-22”

„A. Gupta, V. Harinarayan, D. Quass, Aggregate Query Processing in Data Warehousing Environments, Proc. of the 21st International VLDB Conference,P 358-369,1995”

„V. Harinarayan, A. Rajaraman, J. Ullman, Implementing Data Cubes Efficiently, Proc. ACM SIGMOD, Montreal, Canada, June, 1996”

„J. R. Smith, Dynamic Assembly of Views in Data Cubes, Proc. of the International VLDB Conference (to appear), New York, USA, 1998”

„A. J. Bonner, M. Kifer, An overview of transaction logic, Theoretical Computer Science, vol 133, pp 205-265, October, 1994”

„A. J. Bonner, Transaction Datalog: a Compositional Language for Transaction Programming, Proc. 6th International Workshop on Database Programming Languages, Estes Park, Colorado, August, 1997”

"Sabin Buraga – Tehnologii “XML”, Editura Polirom, Bucuresti, 2006 »

“Julie C. Meloni – Învață singur PHP, MySQL și Apache, Editura Corint, Bucuresti, 2005”

„Patricia Ju – Databases on the web, designing and programing for network access, Editura M&T Books, New York, 1997”

“Sabin Buraga – Tehnologii Web, Editura Matrix Rom, București, 2001”

“Mark Campbell – Web Design Garage, Editura Prentice Hall, 2005”

“Larry Ullman – PHP și MySql pentru site-uri de web dinamice, Editura Teora, Bucuresti, 2006”

„Ronald Bourret – “XML” and Databases, www.rpbourret.com/”XML”/”XML”AndDatabases.”HTML””

« Valentin Ivașcu – Inițiere în PHP și MySql, http://www.oriceon.com/tutorial/”

“Byte.ro – http://www.byte.ro/byte98-05/bd.htm”

« Biblioteca.ase.ro – www.biblioteca.ase.ro/downres.php?tc=5952”

„Builder.com – http://builder.com.com/5100-6388-5035149.”HTML”#Listing%20A”

„Devshed.com – http://www.devshed.com/c/a/PHP/Serializing-”XML”-With-PHP/5/”

„W3Schools – http://www.w3schools.com/”

„Web developers notes – http://www.webdevelopersnotes.com/”

« Domo.ro – http://www.domo.ro/ »