Șabloane de Proiectare în Aplicații Web

CUPRINS

CAPITOLUL I.

INTRODUCERE……………………………………………………………………………………….

1.1. Motivația temei…………………………………………………………………………………..

1.2. Scopurile lucrării…………………………………………………………………………………

1.3. Structura…………………………………………………………………………………………..

CAPITOLUL II.

Șabloane de proiectare in aplicații web………………………………………………..

2.1. Generalități (ce sunt șabloane de proiectare, clasificare, elementele unui șablon)………………………………………………………………………………………………….

2.2. Șabloanele ale aplicației web…………………………………………………………….

CAPITOLUL III.

Descrierea aplicației……………………………………………………………………………

3.1. Domeniul de interes…………………………………………………………………………

3.2. Analiză……………………………………………………………………………………………

CAPITOLUL IV.

Aplicarea șabloanelor de proiectare in aplicații web in aplicația mea…….

4.1. Identificarea și caracterizarea șabloanelor de proiectare………………………..

CAPITOLUL V.

Concluzii…………………………………………………………………………………………………….

Bibliografie……………………………………………………………………………………………

CAPITOLUL I

INTRODUCEREA

Motivația temei

Internetul a intervenit în economie schimbând în mod ireversibil efectuarea tranzacțiilor, acestea însușindu-și formatul electronic ca principală formă de comerț la distanță și așa comerțul online s-a conturat din ce în ce mai mult pe plan internațional. Au apărut numeroase site-uri și firme care se ocupă cu vânzări de produse prin Internet, organizează licitații online , furnizeaza accesul la pagini cu informații în schimbul unor sume de bani, într-un cuvânt abordează o formă sau alta de comerț electronic, domeniu aflat în plină expansiune. Comerțul online are avantajul că piața pe Internet crește foarte mult de la un an la altul. Un site care este bine lucrat, cunoscut și care oferă produse de calitate la prețuri putin mai mici decat celelalte produse existente pe alte site-uri, va avea mai mulți vizitatori și clienti care vor fi dispuși să investească financiar pentru a le cumpăra. În epoca în care trăim lumea este într-o continuă mișcare, iar nevoia de viteză este fundamentală. Totul se rezumă la tranzacții financiare convenabile cât mai rapide și cu un profit imediat cât mai mare.

Am ales ”Șabloane de proiectare” deoarece acestea au pus stăpânire pe soluții care au fost dezvoltate de-a lungul timpului, într-un mod concis și ușor de aplicat. Ideea de a crea un magazin online o folosesc pentru a defini corespunzător imaginea virtuală a afacerii mele. Cu ajutorul unui site web mă pot adresa tuturor persoanelor care navighează pe internet, cărora le pot arăta propria mea ofertă de produse.

În vederea realizării acestei lucrări am considerat oportună alegerea unui site web care promovează vânzarea de produse IT deoarece tehnologia este într-o continuă evoluție și oamenii sunt dispuși să investească în acestea pentru a fii mereu informați, în continuu în pas cu ultimele tehnologii și tot ce este nou în acest domeniu.

Scopurile lucrarii

Aplicația web este o aplicație care poate fi accesată de catre utilizatori prin intermediul unui browser Web.

Cristopher Alexander spunea : “Orice șablon descrie o problema care apare în mod repetat în mediul nostru și apoi descrie esența soluției respectivei probleme într-un asemenea mod incat puteți utiliza solutia de un milion de ori fără să faceți vreodată de două ori acelasi lucru.”

Șabloanele de proiectare pot mări viteza procesului de dezvoltare a unui soft prin modelele de dezvoltare încercate și testate în probleme asemanatoare. Procesul de proiectare a unui soft implică și analizarea unor probleme care pot ajunge vizibile mai târziu în procesul de implementare. Reutilizarea șabloanelor de proiectare poate atrage atenția asupra unor probleme majore ce pot fi cauzate de aspecte greu de remarcat care au nu au fost observate în procesul de proiectare. De asemenea utilizarea acestor șabloane poate face mai ușoară înțelegerea codului pentru dezvoltatorii software familiarizați cu șabloanele respective.

Este posibilă însa și apariția unor dezavantaje în urma folosirii unor design patterns. Datorită faptului că șabloanele de proiectare sunt concepute în general pentru a fi flexibile,utilizarea lor poate duce din cand în cand la o mărire nejustificată a complexității proiectului ce poate mări timpul de dezvoltare și poate leza rezultatele deosebit de bune ale produsului final.

În concluzie, obiectivul acestei lucrări este de a realiza o aplicație web folosind șabloane de proiectare, deoarece acestea fac mai ușor de realizat și atins scopul propus.

Structura

Structura tipică a unei aplicații web

Stratul de prezentare include, de obicei UI și prezentarea logică a componentelor; stratul de afaceri include, de obicei logica de afaceri, fluxul de lucru al afacerii și entitățile componentelor de afaceri, iar opțional, o fațadă, și stratul de date include de obicei accesul la datele și serviciile componentelor agent. 

Considerații generale de proiectare

La proiectarea unei aplicații Web, obiectivul arhitectului software este de a minimiza complexitatea prin separarea sarcinilor în diferite domenii de interes în timp ce proiectarea aplicației oferă o mare performanță. Trebuie să  urmăm aceste instrucțiuni pentru a ne asigura că aplicația îndeplinește cerințele noastre și se efectuează în mod eficient aplicația web:

Partiționăm logic aplicația noastră. Folosim stratificarea pentru a împărți logic aplicația în straturi de prezentare, de afaceri și de acces la date. Acest lucru ne ajută să creăm un cod de întreținut și ne permite să monitorizăm și să optimizăm performanța fiecărui strat în parte. O clară separare logică oferă, de asemenea, mai multe opțiuni pentru scalarea aplicației noastre.

Utilizăm abstractizarea pentru a pune în aplicare un cuplaj slab între straturi . Acest lucru poate fi realizat prin definirea componentelor de interfață, cum ar fi o fațadă cu intrări și ieșiri bine cunoscute care traduce solicitările într-un format înțeles de componentele din cadrul stratului. În plus, putem utiliza, de asemenea, tipurile de interfață sau clasele de bază abstracte pentru a defini o abstracție comună pe care componentele de interfață trebuie să le pună în aplicare.

Să înțelegem cum vor comunica componente între ele . Acest lucru necesită o înțelegere a scenariilor de implementare pentru mai mult suport în aplicația noastră. Trebuie să determinăm dacă comunicare de dincolo de granițele fizice sau limitele de proces trebui să fie suportată, sau în cazul în care toate componentele vor rula în cadrul aceluiași proces.

Să luăm în considerare caching pentru a minimiza călătorii dus-întors de server. Când se proiectează o aplicație Web, luăm în considerare utilizarea tehnicilor cum ar fi caching și de output buffering pentru a reduce călătorii dus-întors între browser și serverul web; și între serverul Web și serverele din aval. O strategie cache bine concepută este probabil unicul aspect important pentru performanța de proiectare. 

Luăm în considerare  logging  și instrumentele. Ar trebui examinate și activitățile de pe straturile și nivelurile de aplicație jurnal . Aceste jurnale pot fi folosite pentru a detecta activitate suspectă , care furnizează frecvent indicii timpurii ale unui atac asupra sistemului . Trebuie să ținem cont de faptul că poate fi dificil să conectăm problemele care apar cu cod script și care rulează în browser .

Luăm în considerare autentificarea utilizatorilor dincolo de granițele de încredere. Trebuie să proiectăm aplicația noastră pentru a autentifica utilizatorii de fiecare dată când traversează granița unui trust; de exemplu, atunci când accesează un strat de afaceri la distanță,de stratul de prezentare.

Nu trecem datele sensibile în întreaga rețea. Ori de câte ori trebuie să trecem date sensibile, cum ar fi o parolă sau autentificarea cookie pentru întreaga rețea, luăm în considerare criptarea și semnarea datelor sau folosim Secure Sockets Layer (SSL).

Proiectăm aplicația Web pentru a o rula folosind un cont puțin privilegiat. Dacă un atacator reușește să preia controlul asupra unui proces, identitatea procesului ar trebui să aibă acces limitat la sistemul de fișiere și la alte resurse de sistem, în scopul de a limita pagubele posibile.

CAPITOLUL II

ȘABLOANE DE PROIECTARE ÎN APLICAȚII WEB

2.1. Generalități

Un șablon de proiectare este o metodă formală de documentare a unei soluții de succes la o problemă de proiectare.

Termenul de șablon (pattern) a fost introdus de arhitectul Christopher Alexander, care a dezvoltat idea unui limbaj de șabloane, pentru a permite oamenilor să-și proiecteze propriile locuințe. Ideea aceasta a fost preluată de dezvoltatorii software care au ajustat-o la domeniul lor de activitate. Principala idee este dezvoltarea de șabloane care să reprezinte soluții la micile probleme de proiectare.

Limbajul de șabloane (pattern language) constă într-un set de șabloane, fiecare prezentând rezolvarea unei probleme particulare. Șabloanele lui Alexander variază în funcție de nivelul de detaliere, ele pornind de la un nivel global; de exemplu : cum poate fi lumea împărțită în țări, țările în regiuni, până la împărțirea pe birouri și plasarea ferestrelor în birouri.

În programare, un design pattern constituie o soluție a unei probleme des întâlnite în procesul de proiectare a unui soft (în software design). Un șablon de proiectare nu este o soluție care poate fi mutată direct în cod, ci o descriere la modul in care se rezolva o problemă. În obiect-orientare un șablon de proiectare arată în general relațiile și interacțiunile care au loc între clase sau obiecte, fară a preciza care sunt clasele sau obiectele finale pe care le vom folosi în aplicația noastră.

Clasificarea șabloanelor de proiectare

Șabloanele de proiectare pot fi clasificate în funcție de tipul problemei pe care o rezolvă. Astfel ele pot fi împărțite în:

Șabloane fundamentale;

Șabloane creaționale. Acestea conțin șabloanele care se ocupă cu crearea obiectelor;

Șabloane structurale. Aici întâlnim șabloanele care tratează relațiile dintre entități;

Șabloane comportamentale. Acestea prezintă șabloanele care tratează comunicarea dintre obiecte;

Șabloane de concurenta

În general , un șablon are patru elemente esențiale:

Numele șablonului este o reprezentare pe care o putem utiliza pentru a descrie în câteva cuvinte problema de proiectare, soluțiile și consecințele ei. Numirea unui șablon mărește imediat vocabularul nostru de proiectare. Ne permite să lucrăm cu un nivel mai înalt de abstractizare. Un vocabular pentru șabloane ne permite să discutam despre ele cu colegii noștri, în documentațiile pe care le scriem și chiar cu noi înșine. El ne ușurează modul în care ne gândim la proiecte și la felul în care comunicam altor persoane șabloanele cu avantajele și dezavantajele lor. Găsirea unor nume bune a fost una dintre cele mai grele părți.

Problema descrie cand se aplică șablonul. Aceasta explică problema și contextul ei. Ea poate descrie probleme specifice de proiectare, ca drn constituie o soluție a unei probleme des întâlnite în procesul de proiectare a unui soft (în software design). Un șablon de proiectare nu este o soluție care poate fi mutată direct în cod, ci o descriere la modul in care se rezolva o problemă. În obiect-orientare un șablon de proiectare arată în general relațiile și interacțiunile care au loc între clase sau obiecte, fară a preciza care sunt clasele sau obiectele finale pe care le vom folosi în aplicația noastră.

Clasificarea șabloanelor de proiectare

Șabloanele de proiectare pot fi clasificate în funcție de tipul problemei pe care o rezolvă. Astfel ele pot fi împărțite în:

Șabloane fundamentale;

Șabloane creaționale. Acestea conțin șabloanele care se ocupă cu crearea obiectelor;

Șabloane structurale. Aici întâlnim șabloanele care tratează relațiile dintre entități;

Șabloane comportamentale. Acestea prezintă șabloanele care tratează comunicarea dintre obiecte;

Șabloane de concurenta

În general , un șablon are patru elemente esențiale:

Numele șablonului este o reprezentare pe care o putem utiliza pentru a descrie în câteva cuvinte problema de proiectare, soluțiile și consecințele ei. Numirea unui șablon mărește imediat vocabularul nostru de proiectare. Ne permite să lucrăm cu un nivel mai înalt de abstractizare. Un vocabular pentru șabloane ne permite să discutam despre ele cu colegii noștri, în documentațiile pe care le scriem și chiar cu noi înșine. El ne ușurează modul în care ne gândim la proiecte și la felul în care comunicam altor persoane șabloanele cu avantajele și dezavantajele lor. Găsirea unor nume bune a fost una dintre cele mai grele părți.

Problema descrie cand se aplică șablonul. Aceasta explică problema și contextul ei. Ea poate descrie probleme specifice de proiectare, ca de exempu cum se reprezintă algoritmii ca obiecte. Ea poate descrie pentru un design inflexibil clase sau structuri de obiect. Uneori problema v-a include o lista de condiții care trebuie îndeplinite înainte de a avea sens să se aplice șablonul.

Soluția descrie elementele care compun designul, relațiile, responsabilitățile și colaborarile acestora. Ea nu descrie un anume design sau o implementare concretă, deoarece un șablon este asemănător unui tipar care poate fi aplicat în multe situații diferite. În loc de acestea , șablonul oferă o descriere abstractă a unei probleme de proiectare și modul în care un aranjament general al elementelor o rezolvă.

Consecințele reprezintă rezultatul și compromisurile ce trebuie făcute la aplicarea șablonului. Desi consecințele, deseori, nu sunt cand explicăm deciziile de proiectare, ele au importanță critica pentru evaluarea alternativelor și pentru întelegerea costurilor și beneficiilor aplicării șablonului.

Consecințele în cadrul software se referă în general la compromisurile ce trebuie facute în privinta spațiului și a timpului. De asemenea, ele se pot ocupa și de probleme de limbaj sau de implementare. Deoarece reutilizarea este deseori un factor important , consecințele unui șablon includ impactul pe care-l are acesta asupra flexibilității , extensibilității sau portabilității unui sistem.Prezentarea acestor consecințe va ajută să le înțelegeți și să le evaluați.

2.2. Șabloanele aplicației web

Problemele specifice de proiectare trebuie să ia în considerare mai multe aspecte comune în timp ce dezvoltam design-ul. Aceste probleme pot fi clasificate în domenii specifice de proiectare.

Secțiunile următoare oferă instrucțiuni pentru  ne ajuta să evităm problemele comune din fiecare domeniu:

Prelucrare de cerere în aplicații

Autentificare

Autorizație

Caching

Managementul excepție

Loggin și instrumente

Navigare

Formatul paginii

Pagina de redare

Managementul sesiune

Validarea

Prelucrarea de cerere în aplicații

La un nivel înalt, o aplicație web poate efectua prelucrarea cererii în două moduri. Cu abordarea mesaj, browser-ul comunică în primul rând cu serverul folosind Web Forms. O abordare alternativă populară este utilizarea apelurilor REST-full între browser și server. Aceste două abordări au fiecare avantaje și dezavantaje, iar alegerea noastră poate avea un impact în abordarea problemelor de proiectare descrise mai jos.

Atunci când alegem o strategie de prelucrare a cererii, ar trebui să luăm în considerare de cât de mult control avem nevoie asupra UI în aplicația noastră, de abordarea pe care am ales-o,de dezvoltare și testare, precum și de performanțele și cerințele scalare.

Abordarea mesaj permite, în general, o experiență de dezvoltare bazată pe formulare și folosește controale server-side care fac HTML corespunzător, în vederea stratului asociat, și logica de interacțiune la browser. Luăm în considerare această abordare, dacă în curs de dezvoltare o aplicație web bazată pe formulare necesită o dezvoltare rapidă a aplicațiilor (RAD) experiență.

Abordarea REST complet permite de obicei un control mai bun pe UI a cererii noastre și oferă o mai mare flexibilitate în ceea ce privește navigația, testabilitate, și separarea de probleme. Luăm în considerare utilizarea acestei abordări, dacă cererea noastră necesită navigare flexibilă, control fin asupra UI. Poate utiliza tehnologii de redare UI alternative, sau dacă utilizați o abordare de dezvoltare bazată pe test.

Indiferent de strategia de prelucrare a cererii pe care o alegem, trebuie să asigurăm separarea preocupărilor prin implementarea logică de procesare a cereii și logica aplicației separată de UI.  Mai multe modele ajută la realizarea acesteia. În general, Model-View-Presenter (MVP) sau modele similare pot fi utilizate într-un Web Forms mesaj. Model-View-Controller (MVC) modelul este de obicei folosit într-o abordare de prelucrare cerere REST-full.

Autentificare

Proiectarea unei strategii eficiente de autentificare este importantă pentru securitatea și fiabilitatea aplicației. Autentificarea necorespunzătoare sau slabă poate lăsa aplicația vulnerabiă la atacuri spoofing, atacuri dicționar, hijack, și alte tipuri de atac. Putem lua în considerare următoarele orientări la proiectarea unei strategii de autentificare:

Identificăm limitele de încredere în straturi ale aplicației Web. Acest lucru ne va ajuta pentru a determina autentificarea utilizatorilor.

Aplicăm practici sigure de gestionare a contului, cum ar fi conturi lockouts si expirări de parolă, politici puternice pentru parolă care specifică lungimea minima a parolei și complexitatea ei.

Utilizăm un mecanism de autentificare pe platforma susținută cum ar fi Windows Authentication atunci când este posibil. În cazul în care ne decidem să utilizăm autentificarea prin formulare, să profite de sprijinul built-in în ASP.NET, fiind un loc de proiectare a unui mecanism de autentificare personalizat. Luăm în considerare utilizarea unui serviciu federalizat sau Single Sign On (SSO), dacă dorim, pentru a permite utilizatorilor să se autentifice pe mai multe site-uri, cu un singur set de acreditări.

Când trebuie să stocăm parolele într-o bază de date, nu le stocăm ca plaintext; în schimb, păstrează o hash a parolei.

Autorizație

Autorizare stabilește sarcinile pe care o identitate autentificată le poate efectua și identifică resursele care pot fi accesate. Proiectarea unei strategii eficiente de autorizare este importantă pentru securitatea și fiabilitatea aplicației. Autorizare necorespunzătoare sau slabă duce la divulgarea de informații, manipularea datelor, precum și creșterea de privilegii. Apărare în adâncime este principiul cheie de securitate pentru a aplica strategia de autorizare a cererii noastre. Luăm în considerare următoarele orientări la proiectarea unei strategii de autorizare:

Să autorizeze utilizatorii ca trec toate limitele de încredere. Utilizăm autorizație URL pentru pagina de acces director control. Accesul la resursele aval folosesc o identitate de încredere bazată pe modelul subsistemului de încredere.

Luăm în considerare granularitatea pentru setările de autorizare. Construirea de autorizare cu prea multă granularitate va crește mai mult decât managementul; cu toate acestea, folosind mai puțin granularitatea se poate reduce flexibilitatea.

Utilizăm personificarea și delegația pentru a profita de audit și de accesul granular controlat specific platformei, dar se ia în considerare efectul pentru performanță și scalabilitate.

Caching

Caching îmbunătățește performanța și capacitatea de reacție a cererii noastre. Cu toate acestea, alegerile caching incorecte și design-ul defectuos cache poate degrada performanța și capacitatea de reacție. Ar trebui să utilizăm cache pentru a optimiza căutări de date de referință, pentru a evita călătoriile dus-întors de rețea, și pentru a evita inutilitatea și duplicarea de prelucrare. Pentru a pune în aplicare cache, trebuie să decidem mai întâi atunci când încărcăm datele în cache. Încercăm să încărcăm date cache asincron sau prin utilizarea unui proces discontinuu, pentru a evita întârzierile client. Luăm în considerare următoarele orientări atunci când în proiectarea cache:

Datele cache să apară în format de utilizare atunci când este posibil, și să evite cache de date volatile, care se schimbă în mod regulat. Evităm cache informații sensibile dacă nu este criptat.

Utilizăm ieșirea caching pentru cache pagini care sunt relative statice. Acest lucru îmbunatățește dramatic performanta, în timp ce încă sprijină variațiile bazate pe valorile prezentate. Dacă doar o parte a paginii este relativ statică, luăm în considerare utilizarea caching pagina parțială cu control pentru utilizator.

Managementul excepție

Proiectarea unei strategii eficiente de management excepție este importantă pentru securitatea și fiabilitatea aplicației. Tratarea exceptiilor corect în paginile noastre de web previn dezvăluirea detaliilor sensibile exceptie la utilizator, îmbunătățește aplicare robustă și ajută la evitarea lăsării aplicației într-o stare inconsistentă în caz de eroare. Luăm în considerare următoarele orientări la proiectarea unei strategii de management excepție:

Furnizează mesaje de eroare prietenoase utilizatorului pentru a notifica utilizatoratorilor erorile din aplicatie, dar ne asigurăm că evităm expunerea datelelor sensibile în pagini de eroare, mesaje de eroare, fișierele și dosarele de audit jurnal.

Ne asigurăm că prinde excepții netratate,curață resurse și de stat atunci când apare o excepție. Proiectează un handler excepție global care afișează o pagină de eroare globală sau un mesaj de eroare pentru toate excepțiile netratate. Trebuie să evităm utilizarea de excepții personalizate, atunci când nu este necesar.

Nu prinde excepții dacă nu trebuie să le manipuleze; de exemplu, pentru a elimina informațiile sensibile sau pentru a adăuga informații suplimentare excepție. Nu folosiți excepții pentru a controla fluxul logic al aplicației.

Loggin și Instrumente

Proiectarea unei strategii eficientă de loggin și instrumente este importantă pentru securitatea și fiabilitatea aplicației. Ar trebui să auditeze și jurnalul aplicației noastre. Aceste jurnale pot fi folosite pentru a detecta activitatea suspectă, care furnizează frecvent indicii timpurii ale unui atac asupra sistemului, și poate contribui la abordarea amenințărilor unde utilizatorii neagă acțiunile lor. Jurnalul și fișierele de audit pot fi necesare în justiție pentru a dovedi o faptă rea a unei persoane. Auditul este în general considerată ca fi cea mai mare autoritate în cazul în care acesta este generat precis în momentul accesului de resurse, și de rutină care accesează resursa. Luăm în considerare următoarele orientări la proiectarea unei strategii de loggin și instrumente:

Luăm în considerare auditul în toate straturile cererii pentru evenimentele de gestionare utilizator, sistem evenimente critice, operațiunile critice de afaceri, precum și activități neobișnuite.

Creăm politici de securitate de gestionare a fișierelor log, cum ar fi restricționarea accesului la fișierele jurnal și permițând doar scrierea pentru accesul utilizatorilor. Ne asigurăm că mecanismele noastre de logare și instrumentate sunt configurabile în timpul implementării și în producție.

Nu stocăm informații sensibile în jurnal sau audit de fișiere.

Navigare

Proiectarea unei strategii de navigare într-un mod care o separă de logica de procesare. Strategia noastră ar trebui să permită utilizatorilor să navigheze cu ușurință prin ecrane sau pagini. Proiectarea unei structuri de navigare consistente pentru aplicația noastra ne va ajuta pentru a minimiza confuzia utilizator, precum și reducerea aparentă a complexității cererii. Luăm în considerare următoarele orientări atunci când proiectăm strategia de navigare:

Dacă utilizăm un Web Forms mesaj abordare, luăm în considerare utilizarea modelelor de design, cum ar fi MVP să decupleze procesarea UI de randare ieșire. Evităm amestecarea logica de navigare cu componentele de interfață de utilizator manipulată de navigarea în Presenter.

Dacă utilizați o abordare REST-full, luăm în considerare utilizarea unui model MVC care să decupleze logic aplicarea, datele și navigarea în componentele separate. Implementare aplicației tipice MVC oferă sprijin în navigare flexibilă prin direcționarea cererii la o componentă controller care coordonează apoi UI și datele aplicației.

Luăm în considerare utilizarea unei hărți a site-ului pentru a ajuta utilizatorii să găsească pagini de pe site și pentru a permite motoarelor de căutare să acceseze site-ul. Ținem seama de utilizarea elementelor vizuale, cum ar fi link-uri încorporate, meniuri de navigare și navigare în UI pentru a ajuta utilizatorii să înțeleagă unde se află, ceea ce este disponibil pe site și cum fac pentru a naviga pe site rapid.

Formatul Paginii

Proiectarea cererii noastre astfel încât aspectul paginii să poate fi separat de componentele UI specifice și prelucrarea UI.  Atunci când alegem o strategie aspect se ia în considerare dacă designerii sau dezvoltatorii vor construi aspectul. Dacă designerii vor construi layout-ul, alegem o abordare de aspect care nu are nevoie de codare sau utilizarea instrumentelor-concentrat de dezvoltare. Luăm în considerare următoarele orientări atunci când proiectăm strategia de aspect:

Să utilizăm Cascading Style Sheets (CSS) pentru layout ori de câte ori este posibil. Cu toate acestea, folosim utilizarea aspectului bazat pe tabelă, atunci când trebuie să susțină un aspect de grilă sau în cazul în care datele sunt reprezentate sub forma unui tabel. Trebuie avut în vedere faptul că aspectul bazată pe tabelă poate fi lent și pot exista probleme cu aspectul complex.

Folosim un aspect comun pentru pagini acolo unde este posibil pentru a maximiza accesibilitatea și ușurința de utilizare. Evităm proiectarea si dezvoltarea de pagini mari, care realizează mai multe sarcini, în special în cazul în care doar câteva sarcini sunt de obicei executate cu fiecare cerere. Trebuie minimizată dimensiunea paginii în cazul în care este posibil pentru a maximiza performanțele și pentru a reduce necesarul de lățime de bandă.

Utilizăm paginile de master în aplicații ASP.NET pentru a oferi un aspect comun și comportamentul pentru toate paginile și pentru a permite actualizări pe site cu un efort minim. Luăm în considerare extragerea secțiunii comune de pagini în controale de utilizator separate pentru a reduce complexitatea generală și pentru a permite reutilizarea acestor controale.

Luați în considerare utilizarea de control de server ASP.NET AJAX si biblioteca client-side ASP.NET AJAX pentru a face script-ul client mai ușor portabil între diferite browsere. De asemenea, evită amestecul script client-side cu codul HTML. Procedând astfel, face pagina mai complexă și mai greu pentru a o menține. 

La migrarea unei aplicații web existente, luați în considerare utilizarea de control Silverlight în paginile ASP.NET pentru a oferi o experiență de utilizare bogată și a minimiza aplicare reengineering.

Pagina de redare

La proiectarea de redare a paginii, trebuie să ne asigurăm că vom face în mod eficient paginile și maximiza interfața de utilizare. Luăm în considerare următoarele orientări la proiectarea unei strategii de pagini de redare:

Luăm în considerare utilizarea script client-side sau ASP.NET AJAX pentru o experiență de utilizare îmbunătățită și o mai bună reacție. Utilizarea scriptului client-side personalizat pot face aplicații mai greu de testat, deoarece sprijinul script variază între diferite browsere și versiuni. În schimb, luăm în considerare utilizarea ASP.NET AJAX, care sprijină browsere mai comune. Ne amintim că utilizarea de cod client-side de orice poate afecta accesibilitatea. 

Ținem cont de opțiunile de legare de date. De exemplu, puteți lega colecții, DataReader obiecte, DataSet tabele și obiecte personalizate la multe controale ASP.NET, care folosesc tehnici de date de paginare pentru a minimiza problemele de scalabilitate asociate cu cantitățile mari de date, precum și pentru a îmbunătăți performanță și răspunsul.

Luăm în considerare proiectarea pentru a sprijini localizare în componente UI.

Managementul sesiune

La proiectarea unei aplicație Web, o strategie eficientă și sigură de gestionare a sesiune este importantă pentru performanță și fiabilitate. Trebuie să ia în considerare factori de management sesiune în cazul în care îl stochează și modul în care informațiile vor fi păstrate de mult. Luăm în considerare următoarele orientări la proiectarea unei strategii a managementului de sesiune:

Luăm în considerare dacă avem, de fapt avem nevoie pentru a stoca starea de sesiune. 

Ne asigurăm că persistă datele sesiune atunci când este necesar, dar luăm în considerare utilizarea read-only a sesiunii sau dezactivarea de stat sesiune , totul pentru a îmbunătăți performanța în cazul în care acest lucru este necesar.

Dacă depozitați stat pe un server separat, pentru a proteja canalul de comunicare de stat sesiune folosind tehnici, cum ar fi SSL sau IPSec.

Preferă tipuri de bază de date de sesiune pentru a reduce costurile serializare.

Validare

Proiectarea unei soluții eficientă de validare este importantă pentru securitatea și fiabilitatea aplicației. Validare necorespunzătoare sau slab poate lăsa aplicația vulnerabilă la atacuri cross-site scripting, atacuri SQL injection, depășirilor de buffer, și alte tipuri de atac de intrare. Luați în considerare următoarele orientări la proiectarea unei strategii de validare:

Validarea tuturor datelor care traversează granițele de încredere ale aplicației. Să presupunem că toate datele client controlate sunt rău intenționate și trebuie să fie validate.

Proiectarea strategiei de validare constrânge, respinge, și igienizează intrarea malițioasă și validareză toate datele de intrare pe baza de lungime, gama, format, și de tip.

Se utilizează validarea client-side pentru o experiență de utilizare optimă și reducerea călătorii dus-întors de rețea, dar validează întotdeauna pe server din motive de securitate.

Considerații de proiectare pentru straturi

Dacă am ales să utilizăm un design stratificat pentru aplicația noastră, luăm în considerare problemele specifice pentru fiecare strat care sunt descrise în următoarele secțiuni.

Prezentare Layer

Stratul de prezentare a aplicației Web afișează UI și facilitează interacțiunea cu utilizatorul. Designul trebuie să se concentreze asupra separării preocupărilor, în cazul în care interacțiunea logică cu utilizatorul este decuplată de la componentele UI. Ar trebui să ia în considerare utilizarea separate a componentelor UI și componente logice de prezentare în interfețe complexe, bazînd componentele UI pe controalele web standard, acolo unde este posibil. Putem compila controalele într-un ansamblu de reutilizare în cadrul aplicațiilor, sau dacă avem nevoie să adăugăm caracteristici suplimentare de control de server existente.

Pentru aplicații Web, stratul de prezentare format dintr-o componentă de server-side (care face HTML) și o componentă client-side (agentul browser sau utilizator care execută script și afișează HTML),în general toată prezentarea logică există în componentele de server și componentele client care afișa numai HTML. 

Business Layer

La proiectare, stratul de afaceri pentru aplicația nostră Web ia în considerare modul de punere în aplicare logica de afaceri și fluxurile de lucru de lungă durată. Folosind un strat de afaceri separat care implementează logica de afaceri și fluxurile de lucru poat îmbunătăți mentenabilitatea și posibilitatea de verificare a cererii noastre și ne va permite să centralizăm și să reutilizăm funcții logice de afaceri comune. Luăm în considerare proiectarea entităților de afaceri care reprezintă datele din lumea reală și folosim aceste date pentru a le trece între componente.

Date Layer

Luăm în considerare proiectarea unui strat de date pentru aplicația noastră Web care abstractizează logica necesară pentru a accesa baza de date. Folosind un strat separat de date face aplicarea mai ușor de configurat și întreținut, dar ascunde detaliile bazei de date de la alte straturi ale cererii. Entitate de design obiectează că stratul de date poate popula sau poate folosi pentru a actualiza sursa de date și de a folosi ca transfer de date obiecte (DTOs), atunci când interacționează cu alte straturi și să treacă pin date între straturi.

Proiectarea stratului de date profita de conectare în comun pentru a reduce numărul de conexiuni deschise și ia în considerare utilizarea operațiunilor de lot pentru a reduce călătorii dus-întors la baza de date. Stratul de date are, de asemenea, nevoie pentru a accesa servicii externe folosind agenți de servicii. De asemenea, ne asigurăm că proiectăm o strategie de manipulare excepție care să se ocupe de erorile de acces la date, precum și pentru a propaga excepții de la stratul de afaceri.

Serviciul Layer

Luăm în considerare proiectarea unui strat serviciu separat, dacă avem de gând să implementăm strat de afaceri pe un nivel de la distanță sau dacă avem de gând expunerea logică de afaceri, folosind un serviciu web. Proiectează servicii pentru a obține reutilizarea maxima, de a nu-și asuma detaliile specifice ale clientilor care le va utiliza și pentru a evita modificările în timp, care ar putea rupe interfața de servicii pentru clientii existenti. În schimb, pune în aplicare versiunea de interfață pentru a permite clienților să se conecteze la versiunea corespunzătoare.

Testare și Testability Considerații

Testabilitate este o măsură care arată de cât de bine sistemul sau componentele noastre ne permit să creăm criterii de testare și să execute teste pentru a determina dacă sunt îndeplinite criteriile. Trebui să se ia în considerare atunci când se concepe testabilitatea arhitecturală, deoarece ea face mai ușorară diagnosticarea problemelelor mai devreme și reduce costurile de întreținere. Luăm în considerare următoarele recomandări pentru testabilitate:

Defineaște în mod clar intrările și ieșirile de straturi si componentelor aplicației în faza de proiectare.

Luăm în considerare modele de prezentare separate, cum ar fi MVC sau MVP în stratul de prezentare. Aceasta permite ca prezentare logică să fie unitate testată.

Proiectază un strat de afaceri separat pentru implementarea logica și a fluxurilor de lucru de afaceri, care îmbunătățește posibilitatea de verificare a cererii noastre.

Componente care pot fi testate individual de proiectarea cuplată slab.

Proiectează o strategie eficientă de exploatare și urmărire, care ne permite să detectăm sau depăm erorile care altfel ar putea fi dificil de găsit. Furnizează loggin și informații de urmărire, care pot fi consumate de către instrumentele de monitorizare sau management.  Acest lucru ne va ajuta să localizăm și să ne concentrăm pe codul defect atunci când apar erori. Fișierele jurnal ar trebui să conțină informații care pot fi utilizate pentru a reproduce problema.

Considerații Tehnologie

Pe platforma Microsoft, din punct de vedere ASP.NET, putem combina modelul ASP.NET Web Forms cu o serie de alte tehnologii, inclusiv ASP.NET AJAX, ASP.NET MVC, Silverlight, și ASP.NET Dynamic Data. Luăm în considerare următoarele orientări:

Dacă dorim să construim aplicații care sunt accesate prin intermediul unui browser Web sau agent utilizator specializat, luăm în considerare utilizarea ASP.NET.

Dacă dorim să construim aplicații care furnizează sporite interactivități și fundalul de prelucrare cu mai puține reîncărcările de pagină, luăm în considerare utilizarea ASP.NET cu Ajax.

Dacă dorim să construim aplicații care includ conținut media bogat și interactivitate, luăm în considerare utilizarea ASP.NET cu controale Silverlight.

Dacă utilizăm ASP.NET, luăm în considerare utilizarea de pagini de master pentru a implementa o interfață consecventă în toate paginile.

Dacă construim o aplicație web de date condusă cu paginile bazate pe modelul de date al bazei de date care stau la baza, luăm în considerare utilizarea ASP.NET Dynamic Data.

Dacă utilizăm o abordare de dezvoltare bazată pe testare sau are nevoie de un control cu ​​granulație fina peste UI noastră, luăm în considerare utilizarea modelului MVC și ASP.NET MVC pentru a curața cerere separată și logica de navigare din UI a cererii noastre.

Considerații de implementare

Când desfășurăm o aplicație Web, trebuie să luăm în considerare modul în care stratul și component de locație va afecta performanța, scalabilitatea și securitatea cererii. S-ar putea, de asemenea, să fie nevoie să ia în considerare compromisuri de design. Utilizarea poate sa fie distribuită sau o abordare de implementare nondistribuită, în funcție de cerințele de afaceri și constrângerile de infrastructură.  Desfășurarea nondistribuită va maximiza performanțele în general prin reducerea numărului de apeluri pe care trebuie să le traverseze granițele fizice. Cu toate acestea, implementarea distribuită va permite să se realizeze o mai bună scalabilitate și e fiecare strat să fie asigurat separat.

NonDistributed Deployment

Într-un scenariu de implementare nondistribuit, toate straturile logic separate ale aplicației Web se află fizic pe același server Web, cu excepția bazei de date. Trebuie să se ia în considerare modul de aplicare care se va ocupa de mai mulți utilizatori simultani și cum să se asigure straturile care locuiesc pe același server. Figura 2.1. prezintă acest scenariu.

Figura 2.1. : Implementarea Nondistributed la o aplicație Web

Luăm în considerare următoarele orientări atunci când alegem o implementarea nondistribuită:

Utilizăm implementarea nondistribuită dacă aplicația noastră web are performanță sensibilă, deoarece apelurilele locale la alte straturi reduc impactul asupra performanței, care ar fi cauzate de apelurile la distanță în toate niveluri.

Dacă nu avem nevoie pentru a partaja logica de afaceri cu alte aplicații și se va accesa numai stratul de prezentare, proiectăm o interfață bazată pe componente pentru stratul de afaceri.

Dacă logica de afaceri și prezentarea logică rulează în cadrul aceluiași proces, evită autentificarea la stratul de afaceri.

Utilizăm o identitate de încredere (prin modelul subsistemului de încredere) pentru a accesa baza de date. Acest lucru îmbunătățește performanța și scalabilitatea aplicației.

Decidem cum vom proteja datele sensibile transmise între serverul web și serverul de baze de date.

Deployment distribuit

Într-un scenariu de implementare distribuită, prezentarea și de straturile de afaceri ale aplicației Web au reședința pe nivele fizice distincte și comunică la distanță. Vom găsi de obicei straturi de afaceri și de acces la date pe același Sever. Figura 3 prezintă acest scenariu.

Figura 2.2. Implementarea distribuită la o aplicație Web

Luăm în considerare următoarele orientări atunci când alegem o implementare distribuită:

Nu implementam strat de afaceri la categoria separată decât dacă este necesar; de exemplu, pentru a maximiza scalabilitate sau atunci când problemele de securitate interzice implementarea logica de afaceri pe serverul nostru Web front-end.

Luăm în considerare utilizarea unei interfețe bazată pe mesaj pentru stratul de afaceri.

Luăm în considerare utilizarea protocolului TCP cu codare binară pentru a comunica cu stratul de afaceri pentru cea mai bună performanță.

Luăm în considerare protejarea datelor sensibile transmise între diferite niveluri fizice.

Load Balancing

Când implementăm aplicația Web pe mai multe servere, putem utiliza load balancing pentru a distribui cererile, astfel încât acestea să fie gestionate de diferite servere Web. Acest lucru ajută pentru a maximiza timpul de răspuns, utilizarea resurselor și tranzitarea. Figura 2.3 prezintă acest scenariu.

Figura 2.3. : Echilibrarea încărcării la o aplicație Web

Luăm în considerare următoarele orientări atunci când proiectarea aplicația Web utilizează echilibrarea încărcării:

Evităm serverul de afinitate la proiectarea aplicațiilor web dacă este posibil, deoarece acest lucru poate afecta negativ capacitatea de aplicare.  Afinitatea Server apare atunci când toate cererile de la un anumit client trebuie să fie manipulate de către același server. În general apare atunci când utilizăm cache local actualizabil în proces sau sesiune locală de magazine de stat. Dacă trebuie să sprijine servere cu afinitate, configurarează traseul cluster pentru toate cererile de la același user la același server.

Luăm în considerare proiectarea componentelor apatrizii pentru aplicația noastră Web; de exemplu, un front-end Web care nu are stare în proces și nici o componentă de afaceri stateful. 

Luăm în considerare utilizarea Windows Network Load Balancing (NLB), ca o soluție software pentru a implementa redirecționarea cererii serverelelor dintr-o fermă de aplicare.

Luăm în considerare utilizarea clustering pentru a minimiza impactul erorilor de hardware.

Luăm în considerare partiționare baza de date pe mai multe servere de baze de date multiple în cazul în care cererea are cerințe ridicate de intrare / ieșire.

CAPITOLUL III

DESCRIEREA APLICAȚIEI

Descrierea Website-ului

Spațiul Web reprezintă o nouă frontieră către o industrie globală, care deschide perspectivă unor noi afaceri. Comerțul actual s-a îmbogățit cu un nou concept: comerțul electronic (e-commerce). Acest tip nou de comerț furnizează noi mijloace de tranzacționare pentru o largă varietate de produse, interconectând o multitudine de piețe din întreaga lume

Această aplicație concepe și implementează o firmă ipotetică, cu tendința de a deveni reală, numită UVT Shop , în ideea de a oferi un website ușor de monitorizat, pentru vânzări online, încercînd să atragă cât mai mulți clienți cumpărători către piața furnizată. Website-ul dispune de o interfață simplă și prietenoasă, și furnizează clienților de pretutindeni posibilitatea de a vizualiza produsele companiei și de a le cumpăra folosind sisteme de plată diversificate: cash, cecuri sau cărți de credit. Aplicația dispune de un modul de administrare, permițând astfel proprietarului magazinului să adauge, să șteargă articole sau să revizuiască anumite comenzi.

3.1. Domeniul de interes

Aplicația își propune să furnizeze un magazin online pentru o firmă fictivă UVT Shop. Totuși, nu există nici o restricție cu privire la soldul de produse. Proprietarul are posibilitatea să adauge orice produse dorește din domeniul IT, indifetent de valoarea acestora. Administratorul site-ului poate să insereze sau să șteargă diverse categorii ale produselor. Fiecare categorie poate dispune de alte subcategorii, astfel încât sarcina grupării articolelor să devină mai ușoară și mai bine structurată.

Pentru această aplicație am utilizat serverul HTTP Apache, MySQL pentru lucrul cu baza de date și PHP pentru realizarea conținutului dinamic al programelor. MySQL este la cel mai utilizat SGBD (Sistem de gestiune a bazelor de date) online, fiind suficient de simplu de utilizat pentru manipularea cu succes a informațiilor corespunzătoare schemei relaționale a bazei de date.

3.2. Analiza

Diagrama bazei de date

Baza de date se numește “magazin” și are în componența sa opt tabele. În figura 3.1 prezentăm diagrama bazei de date.

Figura 3.1: Diagrama bazei de date

Descrierea tabelelor

Tabela “users” – această tabelă conține informațiile cu privire la un client care s-a înregistrat în sistem. Se stochează un nume de utilizator unic, o adresă unică de e-mail și, de asemenea, adresele clientului. Clientului i se oferă facilitatea de plată pentru o comandă prin credit card. Și acest tip de informație este stocată în această tabelă.

Tabela “recuperari” – această tabelă conține două câmpuri. Un câmp reprezintă adresa de e-mail a clientului care și-a uitat parola sa și celălalt câmp conține o cheie generată prin aplicație pentru a verifica faptul că solicitantul unei noi parole este întradevăr un client actual. Această cheie va fi trimisă către adresa de e-mail. Dacă clientul răspunde la e-mail cu cheia transmisă, sistemul va genera o parolă și o va trimite utilizatorului.

Tabela “admin” – putem observa din figura 3.1. că această tabelă conține doar un câmp. Scopul tabelei este de a indica care dintre utilizatorii din tabela “users” are drepturi de administrare. Un administrator poate adăuga/șterge noi articole sau vizualiza/accepta/refuza comenzi lansate de utilizatori.

Tabela “produse” – memorează informațiile despre produsele din stoc ale companiei.Un produs are un identificator unic și corespunde unei anumite categorii. Un produs este descris ca având un nume, un producător, un preț, o imagine și o descriere.

Tabela “produse_spec” – această tabelă conține specificațiile produselor. Fiecare produs poate avea zero, una sau mai multe specificații, stocate în această tabelă.

Tabela “categorii” – în ideea structurării corespunzătoare a magazinului, am organizat articolele pe categorii. Fiecare categorie poate conține produse sau alte subcategorii cu produse.

Tabela “comenzi” – un utilizator poate lansa oricâte comenzi dorește. O comandă este memorată în acestă tabelă, cu informațiile utilizatorului comenzii, data comenzii, prețul total și opțiunea de plată. Comanda are un status. Cănd plasăm o comandă, o nouă comandă are statusul “în așteptare”. După ce a fost revizuită de către administrator, comanda capătă statusul “aprobată” sau “respinsă”, caz în care se va stoca în această tabelă motivația respingerii comenzii, care va fi prezentată ulterior clientului.

Tabela “comenzi_produse” – această tabelă memorează informațiile despre produsele dintr-o anumită comandă.

Descrierea structurală a aplicației

Diagrama de interacțiune dintre module

Aplicația are două module principale: modulul de interfață cu utilizatorul și modulul de administrare. Aceste module sunt dependente de existența bazei de date “magazin”. În figura 3.2 putem observa interacțiunea dintre module, prin prisma bazei de date “magazin”.

Figura 3.2: Diagrama de interacțiune între module

Modulul de interfață cu utilizatorul

Acest modul conține mai multe alte module. Avem câteva module care sunt stocate într-un director (folder) separat, INC. Toate celelalte module sunt conținute în restul interfeței. Vom oferi în continuare explicații asupra pricipalelor module:

“sus.php”

Acest modul este responsabil de asigurarea header-ului către celelalte module din cadrul interfeței cu utilizatorul. Aici se afișează logo-ul UVT Shop și se asigură legătura cu pagina de contact și pagina de cumpărare.

“jos.php”

Acest modul doar afișează în toate celelalte module informațiile de subsol (mai precis, drepturile de copyright).

“cosdecumparaturi.php”

Am implementat aici o clasă care simbolizează posibilitatea de cumpărare a produselor. Această clasă va fi utilizată pentru a stoca produsele pe care clientul (cumpărătorul) dorește să le cumpere. Sunt furnizate aici metode pentru asigurarea posibilităților de adăugare, ștergere și manipulare a cantităților specifice din fiecare produs cumpărat. Aici se vor memora, de asemenea, date cu privire la produsele solicitate, precum: identificatorul produsului, prețul său și cantitatea.

“util.php”

Acest modul este cel mai important modul al aplicației. El conține definițiile funcțiilor prin care se asigură interacțiunea permanentă cu baza de date. Funcțiunile pentru logarea utilizatorului, căutare în vederea stabilirii faptului dacă un utilizator este logat sau nu, funcțiunea de delogare sunt implementate aici. Sunt prezente, de asemenea, toate funcțiunile necesare manipulării informațiilor din baza de date, inclusiv funcțiunile necesare modulului de administrare a aplicației.

Modulele care monitorizează interfața cu utilizatorul actual sunt memorate în directorul rădăcină. Funcționalitatea lor se bazează pe modulul “util.php” și modulul “cosdecumparaturi.php”. Aceste aspecte vor fi explicitate mai pe larg în continuare:

“index.php”

Acest modul afișează conținutul coșului de cumpărături prin intermediul a două butoane care pot realiza redirecționarea către modulul de manipulare a conținutului coșului de cumpărături și un altul care poate goli acest coș de cumpărături, catalogul ce conține categoriile principale, un formular de logare sau opțiuni legate de autentificarea conectării dacă utilizatorul este corect legat (conectat) la sistem și în cele din urmă două butoane pentru crearea unui nou utilizator și pentru regăsirea parolei uitate.

“login.php”

Dacă utilizatorul introduce în formularul de logare o combinație corectă a numelui de utilizator și a parolei, formularul de logare este substituit prin legături către opțiunile posibile ale contului, precum: delogare (logout), istoricul comenzii (order history), detalii despre cont (account details), schimbarea parolei (change password) etc. Această operațiune asigură conectarea utilizatorului la sistem.

“logout.php”

După ce un utilizator și-a terminat treaba el se poate deconecta de la sistem folosind link-ul logout.

“catalog.php”

Când un utilizator click-ează asupra unei categorii pricipale, el va fi redirecționat către modulul acestui catalog. Imaginea categoriei este vizualizată. Dacă acea categorie mai conține produse, acestea vor fi afișate prin intermediul unui link către modulul “produs.php” și către un buton de adăugare la coșul de cumpărături; dacă există subcategorii, acestea vor fi afișate prin intermediul unei imagini și a numărului de produse conținute. O subcategorie devine categorie în momentul cânt a fost activată prin click de mouse.

“produs.php”

Când o legătură către un produs a fost click-ată, acest modul este responsabil de vizualizarea informațiilor despre acel produs stocate în baza de date și un buton de adăugare a produsului la coșul de cumpărături.

“cosulmeu.php”

Un utilizator poate modifica conținutul coșului de cumpărături. El poate elimina sau modifica cantitățile dintr-un produs. Această pagină afișază o schemă pentru operațiunile necesare pentru completare unei comenzi. Clientul are posibilitatea să revină asupra procesului de cumpărare sau poate să continue procesul de completare a comenzii.

“comanda.php”

Acest modul este imediat următor celui de constituire a coșului de cumpărături. Acest modul este accesibil doar dacă utilizatorul s-a conectat cu succes la sistem. În această situație, conținutul coșului de cumpărături este arătat prin intermediul unui buton care realizează un link către modulul ce tratează manipularea coșului de cumpărături. De asemenea, se realizează link-uri către modulul de manipulare a detaliilor de autentificare pentru stabilirea adresei de livrare a comenzii, precum și modulul prin care se stabilește opțiunea de plată a comenzii respective.

“plaseazacomanda.php”

Acest modul este accesibil numai prin modulul “comanda.php” și este responsabil cu adăugarea unei noi comenzi în baza de date, în conformitate cu conținutul coșului de cumpărături.

“contulmeu.php”

Un client își poate modifica informațiile sale personale, ca de exemplu, dacă vrea să-și schimbe adresa de livrare sau să-și adauge un credit card. Aceste acțiuni sunt accesibile numai după ce clientul a reușit să se logheze cu succes.

“comenzi.php”

Un client poate vizualiza aici detaliile cu privire la comanda realizată. El poate vedea comenzile actuale precum și unele dintre comenzile anterioare, realizate în trecut. Dacă o comandă este reziliată, clientul poate să vadă motivul refuzării aceste comenzi și să încerce remedierea problemei. În plus, el poate să reconfirme comanda prin utilizarea modulului “reconfirmare.php” sau să anuleze comanda prin intermediul modulului “anuleaza.php”, ambele module fiind accesibile prin intermediul link-urilor. Și în această situație, acțiunile sunt accesibile numai după ce clientul a reușit să se logheze cu succes.

“schimbaparola.php”

Un client poate schimba oricând dorește unele elemente de autenticicare, de exemplu parola de acces (account password). Aceste acțiuni sunt accesibile numai după ce clientul a reușit să se logheze cu succes.

“register.php”

Un client nou poate naviga prin catalogul de produse și adăuga articole la coșul de cumpărături. Dacă el dorește să facă o comandă dar nu are un cont personal, atunci poate să click-eze pe un buton de creare al unui cont de utilizator, prin intermediul acestui modul. Există aici un formular catre urmează să fie completat cu informații personale, alegând un nume de utilizator și o parolă și furnizând adresa de e-mail. Opțional, el poate adăuga un credit card la contul său în vederea efectuării cumpărăturilor online.

Modulul de administrare

Modulele PHP necesare pentru administrare sunt stocate într-un director (folder) special, numit ADMIN. Administratorul poate apela acest modul foarte simplu, prin specificarea căii de accces (path) către acest director în URL.

Multe dintre modulele pe care le prezint realizează acțiuni de actualizare a bazei de date și returnează către alte module informașiile ce urmează a fi afișate.

“index.php”

Acest modul afișează un formular de logare la sistem. Dacă utilizatorul s-a conectat cu succes și numele său de utilizator (username) se găsește în tabela “admin”, atunci el este redirecționat către modulul “admin.php”.

“admin.php”

Acest modul evidențiază numărul produselor, categoriile, subcategoriile, utilizatorii și comenzile. Există, de asemenea, un meniu cu link-uri către modulele de monitorizare a produselor, utilizatorilor și comenzilor.

“produse.php”

Administratorul poate vedea o listă a principalelor categorii eventual și cu subcategorii, care poate fi selectată și ștearsă folosind modulul “delc.php”. Aici, administratorul poate specifica un nou nume de categorie și o imagine pentru aceasta, și utilizând modulul “addc.php” el poate astfel adăuga o nouă categorie. Click-ul pe o categorie ne conduce la același modul, dar există alte opțiuni precum adăugare subcategorie (“addc.php”) sau adăugare/modificare/ștergere (“produs.php”/” addp.php”/” delp.php”).

“produs.php”

Un produs poate fi modificat. Acest modul afișază informațiile despre produs care pot fi modificate și actualizate folosind modulul PHP “actualizeaza.php”. De asemenea, specificația produsului poate fi inserată aici.

“users.php”

Acest modul afișază lista utilizatorilor și ștergerii acestora folosind modulul “delu.php”. De asemenea, este specificat aici dacă utilizatorul are un credit card și el are comenzi lansate.

“comenzi.php”

Acest modul afișează comenzile grupate după următoarel criterii: în așteptare (pending), confirmate (confirmed) și respinse (denied). Un click pe butonul de editare va determina administratorul să utilizeze modulul “detaliicomanda.php”, pentru evidențierea detaliilor comenzii.

“detaliicomanda.php”

O comandă este aici vizualizată. Administratorul poate aproba/ /respinge/șterge o comandă folosind “confirma.php”/”refuza.php”/ /”sterge.php”. Când o comandă este respinsă, administratorul poate specifica motivul pentru care a fost respinsă. Când utilizatorul click-ează asupra detaliilor comenzii în contul său, el poate vedea motivul respingerii comenzii și poate încerca remedierea problemei dacă dorește, sau renunțarea la comandă.

“logout.php”

Acest modul deconectează administratorul din zona de administrare, redirectându-l către modulul “index.php” localizat în directorul rădăcină.

Note de instalare

Se copiază fișierele aplicației în directorul htdcos.

Folosind aplicația phpMyAdmin, baza de date “magazin” trebuie să fie creată. În directorul SQL poate fi găsit un fișier text care conține structura bazei de date în limbaj SQL. Astfel, baza de date poate fi utilizată în orice moment.

După interogare, administratorul trebuie să viziteze pagina și să utilizeze modulul “register.php” pentru a crea contul de administrator. El trebuie să specifice numele de utilizator (username) admin.

CAPITOLUL IV

APLICAREA ȘABLOANE DE PROIECTARE ÎN

APLICAȚIA MAGAZINULUI ONLINE

Deoarece în capitolul anterior am descris doar aplicația, în cadrul acestui capitol vom identifica și caracteriza șabloanele de proiectare pe care le-am utilizat în crearea acesteia.

Șabloanele relevante folosite în proiectarea aplicaților web sunt organizate în categorii, cum ar fi Caching, Management Excepție, Logging și Instrumentație, Aspect pagină, de prezentare, cerere de procesare și Serviciul de interfață Layer, așa cum arată în tabelul de mai jos. Trebuie să luăm în considerare utilizarea acestor modele, atunci când luăm decizii de design pentru fiecare categorie.

Deoarece aplicația UVT Shop obligă clienții de a-și crea cont pentru a putea achiziționa produsele existente în magazinul meu online, putem identifica un prim șablon, și anume șablonul numit Exception Shielding.

Exception Shielding reprezintă filtrul de excepție pentru datele care nu trebuie să fie expuse la sisteme externe sau utilizatori.

Obiectivele acestui model sunt:

Împiedicarea serviciul Web să divulge informații sensibile din mesajele de excepție.

Să creeze excepții care sunt sigure la proiectare, în care informația excepție este returnată clienților de servicii Web.

Scrie detalii excepție pentru un jurnal pentru a sprijini monitorizarea și depanarea serviciul Web.

Strategia pentru punerea în aplicare a acestui model include următoarele:

Punerea în aplicare a unei excepții, de obicei pentru a reveni la datele bune ale clientului, care să nu dezvăluie informații sensibile despre serviciul Web, cum ar fi siruri de caractere de conexiune de baze de date și adrese URL de resurse.

Includem tot codul în blocuri de try/catch.

Participanții

Modelul Exception Shielding implică următorii participanți:

Client . Clientul accesează serviciul Web. Clientul oferă acreditările pentru autentificarea în timpul cererii la serviciul Web.

Serviciu . Serviciul este serviciul web care necesită autentificarea unui client înainte de autorizarea clientului.

Proces

Modelul Exception Shielding descrie procesul pentru a preveni informații excepție detaliate despre revenirea la un client. Acest model de implementare furnizează o descriere detaliată a acestui proces, care este specifică pentru punerea în aplicare.

Figura 4.1: Modul in care un serviciu web prelucreaza mesajele exceptie detaliate de la o exceptie.

Procedeul utilizează următoarele etape:

Clientul depune o cerere la serviciul .

Serviciul încearcă să proceseze cererea și aruncă o excepție . Excepția ar putea fi în siguranță de proiectare sau nesigură.

Logica excepție de protecție procesează excepția . Dacă tipul excepției este sigur prin design, este considerat igienizat și serviciul poate reveni la client nemodificat. Dacă excepția este nesigură, atunci ea este înlocuită cu o excepție care este sigur prin design, unde serviciul poate reveni la client.

Serviciul returnează excepția prelucrată clientului.

Tot în această aplicație este conținut și șablonul Composite View.

Composite View combină vizualizări individuale într-o reprezentare compozit.

Construirea de aplicații compuse este un demers complex, care implică aplicarea unor modele diferite. Acest subiect descrie modele de design în Ghidul de aplicare Composite pentru WPF (Windows Presentation Foundation). Figura 4.2. prezintă o arhitectură tipică aplicației compusă cu ajutorul aplicației Biblioteca Composite și unele comune modele.

Figura 4.2. : Modele de aplicații compozite

Această secțiune oferă o scurtă prezentare a fiecărui model enumerat și o zonă în de cod în graficul aplicației Composite pentru a vedea un exemplu din acest model. Următoarele modele sunt descrise:

Șablonul Composite User Interface :

Composite and Composite View

Command

Adapter

Șabloane de modularitate:

Separated Interface and Plug In

Service Locator

Event Aggregator

Façade

Șabloane Testability :

Inversion of Control

Separated Presentation

Composite and Composite View

În centrul unei aplicații Compozite este abilitatea de a combina opiniile individuale într-o vedere Compozit. Frecvent, definește în vederea compunerii un aspect pentru opiniile copilului. De exemplu, învelișul aplicației poate defini o zonă de navigație și o zona de conținut pentru a găzdui opiniile copilului la momentul execuției, așa cum se arată în figura 4.3.

Figura 4.3. : Exemplu Compozitie

Șablonul Compozit View este o variantă a modelului Compozite.

La implementarea în Stock Trader Reference (Stock Trader RI) a aplicației , poate fi văzută utilizarea regiunilor în coajă. Coaja definește modulele regiunilor localizate și adăuga vederi la timpul procesului de inițializare.

CAPITOLUL V

CONCLUZII

Site-ul realizat este doar unul din site-urile din țara noastră realizat pentru a efectua tranzacții online în domeniul articolelor IT, dar este specific pentru ansamblul acestora.

Acest site se remarcă prin modurile proprii de implementare a tehnicilor de Web Marketing, punând în evidență atât puncte forte cât și pe cele slabe din punct de vedere al teoriei de eficientizare a siteurilor comerciale, care îndeplinesc cu succes rolul de mijloc de informare și de tranzacționare a produselor.

Crearea website-ului este doar un prim pas, adevărata provocare este reprezentată de menținerea contactului cu vizitatorii prin oferirea de informații și actualizarea acestora, de aceea satisfacția vizitatorilor privind pagina web, trebuie înțeleasă ca o condiție de bază. În realizarea acestui scop, recomandăm:

• optimizarea site-ului realizată prin înscrierea lui în Directoare Web și în cele mai populare motoare de căutare pentru a crește numarul de vizitatori pe site ;

• propunerea unor oferte de calitate ridicată, la prețuri mai mici, care să inducă clienților o imagine pozitivă privind achizițiile online;

• inserarea de chestionare în cadrul siteului, folosite pentru a testa eficiența paginilor, dar și pentru a culege informații despre vizitatorii acestuia. Pe baza informațiilor prezente în bazele de date, se poate determina categoria de produse cu impact cât mai mare asupra clienților.

Comerțul pe Internet presupune vânzarea de produse și servicii consumatorilor sau afaceri pe Internet.

Noua economie se supune principiului conform căruia cu cât mai multe persoane se implică cu atât avantajul pentru fiecare implicat este mai mare (“the more people involved the bigger benefit for everyone involved”).

BIBLIOGRAFIE

https://msdn.microsoft.com/en-us/library/ee658099.aspx

https://msdn.microsoft.com/en-us/library/ff650043.aspx

https://msdn.microsoft.com/en-us/library/ff921146.aspx

http://www.preferatele.com/docs/informatica/4/programarea-aplicati12.php

http://biblioteca.regielive.ro/proiecte/calculatoare/sabloane-de-proiectare-a-interfetelor-utilizator-pentru-aplicatii-web-limbaje-de-programare-106700.html

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, DESIGN PATTERNS, Editura Teora, 1995.