Universitatea politehnica facultatea de electronica telecomunicatii si tehnologia informatiei

UNIVERSITATEA POLITEHNICA

FACULTATEA DE ELECTRONICA TELECOMUNICATII SI TEHNOLOGIA INFORMATIEI

Paralela intre MVC Design Pattern si Arhitectura N-Tiers.

Exploatarea Bazelor de date in cele doua concepte prezentate.
Proiect Instrumente Software

Prof. coordonator: Studenti:

Stefan Stancescu Olaru Gheorghe Stefan

Petrescu Mihai Gabriel
BUCURESTI 2015

CUPRINS

PARTEA I- Olaru Gheorghe Stefan 3

1.Prezentare MVC Design Pattern cu exemplu 3

2.Prezentare N-Tiers Architecture cu exemplu 8

3.Diferente intre cele doua concepte 11

Partea a ii-a- Petrescu Mihai Gabriel 12

4.Prezentarea instrumentelor si functionarea Bazei de Date cu exemplu. 12

5.Locul Bazelor de date in MVC 21

6.Locul bazelor de date in N-tiers 21

BIBLIOGRAFIE 22

PARTEA I- Olaru Gheorghe Stefan

1. Prezentare MVC Design Pattern cu exemplu

Model–View–Controller (MVC) reprezinta un model de arhitectura de software pentru implementarea interfetelor utilizatorului. Acesta divide o aplicatie software data, in trei parti interconectate.

Acest concept a fost creeat de Trygve Reenskaug, programator la

Smalltalk, in anul 1979.

Asa cum si numele sugereaza, aplicatia este impartita in trei parti diferite: Model, View si Controller-ul.

Principalul avantaj al MVC-ului il reprezinta refolosirea, in sensul ca poti refolosi acelasi model pentru mai multe view-uri.

Sursa:http://theapplady.net/wp-content/uploads/2013/01/mvc.png

Pentru a putea expune mai bine acest concept, am ales sa il exemplific pe o aplicatie mobila.

Model

Model-ul contine date, informatii,logica. De exemplu un obiect Book , poate contine informatii referitoare la o carte cum ar fi: autor si titlu. In plus, obiectul Book poate relationa cu alte obiecte stabilind relatii una-la-una sau una-la-mai multe. De exemplu, obiectul Book poate relationa cu un obiect Category unde o Category poate contine mai multe obiecte de tipul Book. Obiectele de tip Model isi obtin datele fie din baze de date fie din fisiere care pot fi locale sau externe. Un Model nu comunica direct cu un View insa ii este disponibil unui Controller care il acceseaza in caz de nevoie. In iOS de exemplu, un Model reprezinta o subclasa a NSObject sau in cazul unei Core Data

( un framework iOS care permite salvarea de date intr-o baza de date locala pe un dispozitiv mobil ) o subclasa a NSManagedObject. Fiecare obiect de tip Model contine variabile de instanta si metode de getter/ setter. Majoritatea limbajelor obiect-orientate au un mecanism care asigura incapsularea, in iOS o proprietate asigura incapsularea si cuvantul cheie, synthesize, genereaza automat metodele de getter si setter. In cazul obiectului Book vom avea metode ca getTitle si setTitle sau getAuthor si setAuthor.

Sursa: http://i.imgur.com/XC83j.jpg

View

View-ul afiseaza informatii continute in Model. De exemplu, poate afisa o lista de carti asa cum am mentionat in exemplul de mai sus. Desi View-ul nu obtine informatii in mod direct de la Model, foloseste Controller-ul ca un mediator care il intruieste cand si ce sa afiseze.

In iOS, majoritatea View-urilor subclaseaza din UIView care ofera

capacitatea de a manevra/dirija evenimentele de atingere a ecranului sau de desenare. Framework-ul UIKit contine clase care deseneaza elemente de interfata tipice cum ar fi listele, butoanele, campurile de text si asa mai departe. Mai jos se afla o lista de carti afisate utilizand clasa UITableView.

Sursa: http://i.imgur.com/YwQ3v.jpg

Controller

In final, Controller-ul este responsabil de accesarea de date din Model si afisarea lor in View. Acelasi Controller poate fi folosit pentru a face legatura dintre mai multe View-uri si Modele. Controller-ul monitorizeaza interactiunea utilizatorului cu View-ul si comunica toate modificarile Model-ului. Pe de alta parte, modificarile din Model sunt observate de Controller si succesiv reflectate in View. Controller-ul este de asemenea locul in care se gaseste intreaga aplicatie. In iOS, Controller-ul este in general o clasa a UIViewController care organizeaza View-ul. Este de asemenea responsabil si de mesajele de delegate si mesajele target-action. Mai jos am atasat un UITableViewController care este subclasa a UIViewController si care organizeaza un UITableView (lista).

Sursa:http://i.imgur.com/Hfx1o.jpg

2. Prezentare N-Tiers Architecture cu exemplu

Arhitectura N-Tier este un model de arhitectura software potrivit pentru aplicatii client/server la nivel de intreprindere si care rezolva unele probleme cum ar fi scalabilitatea, securitatea, toleranta la erori, etc.

Diferente si relatii intre terminologii.

Tier si Layer.

Prima data voi clarifica diferenta dintre acesti doi termeni care sunt de multe ori incurcati sau folositi necorespunzator. Tier, reprezinta implementarea fizica a unui calculator. De obicei, un server care functioneaza individual reprezinta un Tier. Mai multe servere se pot numara tot ca si un singur Tier. In contrast, Layer-ul este reprezentat de componente software logice grupate de obicei dupa

functionalitate; Layer-ul este folosit in scopul dezvoltarii software.

Fiecare Layer poate rula intr-un Tier individual dar mai multe Layere

pot de asemenea rula intr-un singur Tier.

Tier si Process

Daca un Layer poate rula intr-un proces individual, de obicei va putea sa ruleze si intr-un calculator(Tier), mai mult este considerat ca fiind capabil sa fie un Tier individual intr-o arhitectura N-Tier.

Layer si Process

Un Layer poate rula intr-un proces individual; mai multe Layere pot rula intr-un proces individual; un Layer poate rula in mai multe procese de asemenea.

Arhitectura 3-Tier

O sa introduc prima data acest concept pentru ca mai apoi sa pot explica conceptul N-Tier mai usor. Cea mai simpla arhitectura N- Tier este 3-Tier care contine in mod obisnuit urmatoarele straturi de componente software de la cel mai de sus nivel la cel mai de jos: Presentation Layer, Application Layer si Data Layer.

Un Layer poate accesa direct doar componentele publice din Layer- ul imediat subordonat. De exemplu, Presentation Layer poate accesa doar componentele publice din Application Layer dar nu si din Data Layer. Application Layer poate accesa componentele publice din Data Layer dar nu si din Presentation Layer. Facand asta se poate minimiza dependenta dintre un strat fata de altele. Aceasta minimizare a dependentei va aduce beneficii pentru mentenanta/ dezvoltarea, imbunatatirea si scalabilitatea Layer-ului respectiv. Facand acest lucru, devine posibila si imbunatatirea securitatii unui Tier. De exemplu, un Client Layer nu poate accesa Data Layer in mod direct ci doar prin Application Layer deci Data Layer are un nivel de securitate ridicat.

Pentru a obtine o arhitectura 3-Tier completa, toate cele 3 Layere ar trebui sa ruleze pe calculatoare separate.

Mai jos este reprezentata Arhitectura 3-Tier.

Imagine: http://www.codeproject.com/Articles/430014/N-Tier-Architecture-and-Tips

Presentation Layer reprezinta un strat pe care utilizatorii il pot accesa direct cum ar fi, interfata unui utilizator de desktop sau o pagina web etc. Mai este numit si Client Layer.

Application Layer : acest strat incapsuleaza logica de business(cum ar fi regulile de business si validarile de date), conceptul de domeniu, logica accesului la date si asa mai departe. Se mai numeste si Middle Layer.

Data Layer : reprezinta data sursa externa care inmagazineaza datele aplicatiei respective cum ar fi serverul bazei de date, sistemul CRM, sistemul ERP, sistemele de mostenire etc. Cel pe care il intalnim cel mai des este serverul bazei de date. Pentru o arhitectura N-Tier trebuie folosite baze de date care nu sunt auto-incluse cum ar fi SQL server , Oracle, DB2, MySQL sau PostgreSQL. Acestea pot sa ruleze pe un singur calculator.

Arhitectura N-tier

Unele straturi din arhitectura 3-Tier pot fi impartite in alte straturi. Aceste straturi pot sa ruleze in mai multe Tiers. De exemplu, Application Layer poate fi impartit in Business Layer, Persistance Layer sau mai multe. Presentation Layer poate fi impartit in Client Layer si Client Presenter Layer. Client Presenter Layer, Business Layer si Data Layer ar trebui sa ruleze in trei calculatoare separate (Tiers).
Imagine: http://www.codeproject.com/Articles/430014/N-Tier-Architecture-and-Tips
Client Layer: acest strat este implicat cu utilizatorii in mod direct. Pot fi mai multe tipuri coexistente cum ar fi WPF, formulare Window, pagini web HTML.

Client Presenter Layer: contine logica prezentarii de care au nevoie clientii cum ar fi ASP, .NET etc. De asemenea adapteaza diferiti clienti la Business Layer.

Business Layer : incapsuleaza toate domeniile si logica de business, mai este numit si Domain Layer.

Persistance Layer: se ocupa de citirea/scrierea datelor de business in

Data Layer, mai este numit si Data Access Layer (DAL). Data Layer: data sursa externa, o baza de date.

3. Diferente intre cele doua concepte

La prima vedere, arhitectura N-Tire pare similara cu conceptul MVC desi din punct de vedere al topologiei, ele nu sunt la fel. O regula de baza intr-o arhitectura N-Tier este reprezentata de faptul ca Layer-ul Client nu acceseaza niciodata direct al treilea Layer , toate accesarile din aceasta arhitectura trebuie sa treaca prin Layer-ul din mjloc.

Astfel aceasta arhitectura este una liniara pe cand conceptul MVC prezinta o arhitectura triunghiulara:View-ul comunica cu Controller- ul, acesta modifica Modelul si astfel View-ul este apoi iar modificat.

MVC reprezinta un design pattern, un concept de organizare al codului sursa cu scopul de a optimiza timpul de lucru al unui programator pe cand N-Tier reprezinta o arhitectura care organizeaza infrastructura de lucru: clientul(browsere, telefoane etc), serverul web, si baza de date a serverului, toate fiind pe statii separate/device-uri.

In aplicatiile mai mari, MVC reprezinta defapt Presentation Layer al unei arhitecturi N-Tier. MVC pot upmple modelele cu date din Data Tier. MVC poate fi angajat si ca o arhitectura 3-Tier in care View-urile sa reprezinte Presentation Layer, Controller-ele sa reprezinte Business Logic (BS) si Modelele sa reprezinte Data Access Layer.

Partea a ii-a- Petrescu Mihai Gabriel

4. Prezentarea instrumentelor si functionarea Bazei de Date cu exemplu.

Pentru a putea expune aceste concepte si instrumente intr-un mod mai clar, am ales drept studiu de caz/exemplu Core Data.

Core data reprezinta un framework foarte util al SDK-ului pentru MAC OS sau iOS care le permite programatorilor sa stocheze si sa lucreze cu date intr-o maniera obiect-orientata.
In mod traditional, programatorii terbuiau sa stocheze datele lor pe disc utilizand arhivarea oferita de Objective-C sau sa isi scrie datele pe fisiere si sa le organizeze/modifice/foloseasca manual. O data cu introducerea Core Data, programatorii pot sa interactioneze simplu cu interfata obiect-orientata pentru a-si manevra datele in mod eficient.
Mai jos voi expune cum poate fi folosita Core Data pentru a creea un model al unei aplicatii folosind design pattern-ul MVC.
Core Data interactioneaza cu un persistent store(un fel de magazie) la un nivel mai jos care nu ii este vizibil programatorului. Acesta trebuie doar sa stie ca la un nivel mai inalt al API-ului se afla si acest persistent store insa intelegerea structurii Core Data si cum functioneaza intern este foarte importanta.
Avand disponibil ultimul compilator LLVM(Low Level Virtual Machine), tot ce trebuie sa facem pentru a folosi Core Data in proiect, este sa includem fisierul .h :
#import "AppDelegate.h"

#import

@implementation AppDelegate

<# Rest of your code goes here #>

Pentru a putea lucra efectiv cu Core Data trebuie sa intelegem ca este bazate pe urmatoarele concepte:

Persistent store
Obiectul care reprezinta defapt baza de date pe disc. Nu folosim niciodata acest obiect in mod direct.
Persistent store coordinator
Obiectul care coordoneaza citirea si scrierea informatiei de la si in Persistent store. Acesta reprezinta puntea de comunicare dintre Managed Object Context si Persistent store. Aici este locul unde se seteaza numele si locatiile pe care baza de date le va folosi pentru a stoca obiectele si de fiecare data cand Managed Object Context va trebui sa salveze ceva, va trece prin acest Persistent store coordinator.
Managed object model (MOM)
Reprezinta un simplu fisier pe disc care va reprezenta modelul

datelor. Putem sa ne gandil la el ca la o schema a bazei de date. Este o clasa care contine definitii pentru fiecare obiect (numite si entitati) pe care il stocam in baza de date. De obicei se foloseste editorul vizual pentru a seta ceva obiecte vrem sa introducem in baza de date,

fiecare cu atributele lor si cum relationeaza fiecare cu fiecare, mai simplu ce relatii au.

Managed object
Aceasta clasa reprezinta entitatea care va fi stocata in Core Data. Programatorii mai numesc aceste entitati si tabele. Un Managed Object este de tipul NSManagedObject si instantele lui se regasesc in Managed Object Context. Ele adereaza la schema dictata de Managed Object Model si sunt salvate in Persistent Store prin intermediul unui Persistenet store coordinator.

Managed object context (MOC)
Acest obiect poate fi reprezentat ca o tabla virtuala. Noi cream obiecte Core Data in memorie si le setam proprietatile si le manevram cum dorim. Aceasta manevrare/organizare este implementata intr-un Managed object context. Contextul pastreaza o referinta catre toate lucrurile pe care le facem cu Managed objects si chiar ne ofera posibilitatea de a anula acele actiuni. De fiecare data cand va trebui sa adaugam obiecte , sa aplicam metode de getter pe ele sau sa le stergem, apelam defapt metode pe Managed Object Context. Acestui obiect ii putem salva starea de fiecare data cand am terminat de adus modificari bazei de date. Cand aceasta salvare are loc, aceasta actiune este comunicata la persistent store coordinator la care este conectat contextul, apoi persistent store coordinator va inmagazina informatia in persistent store si de aici pe disk.

Pentru a implementa bazele de date in aplicatie, urmatoarele proprietati de delegate vor trebui introduse:

NSManagedObjectContext *managedObjectContext; NSManagedObjectModel *managedObjectModel; NSPersistentStoreCoordinator *persistentStoreCoordinator;
Pentru a creea structura bazei noastre de date vom folosi fisierul ($PROJ_NAME).xcdatamodeld unde putem adauga entitati(tabele) si relatii. Fisierul arata ca mai jos:

(Printscreen editat dintr-un proiect personal)
Adaugarea de atribute si relatii tabelei noastre este de asemenea simpla:

Page 14 of 19

(Printscreen editat dintr-un proiect personal)

(Printscreen editat dintr-un proiect personal)

Inserarea

In clasa de delegate a aplicatiei, adaugati acest cod bloc in metoda didFinishLaunchingWithOptions

NSManagedObjectContext *context = [self managedObjectContext]; NSManagedObject *failedBankInfo = [NSEntityDescription
insertNewObjectForEntityForName:@"FailedBankInfo" inManagedObjectContext:context];
[failedBankInfo setValue:@"Test Bank" forKey:@"name"];

Sursa cod:http://www.stackoverflow.com

Pentru a adauga o noua intrare folosim metoda insertNewObjectForEntityForName care creeaza o noua instanta si in care putem seta valori ca atributul “name” de exemplu.

La rularea acestui cod, o instanta locala este creeata dar insa nu este salvata pe disk, asa ca daca am restarta aplicatia, noua intrare nu va fi vizibila. Pentru a rezolva aceasta problema, va trebui sa apelam metoda [context save:&error] pentru a salva modificarile in baza de date.
NSError *error;

if (![context save:&error]) {

NSLog(@"Whoops, couldn't save: %@", [error localizedDescription]);

^}
Sursa cod: http://www.stackoverflow.com
Query (Accesarea de date)
Pentru a efectua un query Core Data, cream un nou obiect denumit si fetch request(cerere de returnare). Ne putem gandi la un fetch

_{request ca la un SELECT obisnuit.}

NSFetchRequest *fetch = [NSFetchRequest fetchRequestWithEntityName:@"Person"];

NSString *nameToGet = @"Ryan";

NSPredicate *predicate = [NSPredicate predicateWithFormat:@"name = %@", nameToGet];

[fetch setPredicate:predicate];
NSError *error = nil;

NSArray *results = [[self managedObjectContext]

executeFetchRequest:fetch error:&error];
if(results) {

NSLog(@"Entities with that name: %@", results);

for(Person *p in results) { NSLog(@"person = %@", p);

}

return results;

} else {

^{NSLog(@"Error: %@", error);}

}
Sursa cod: http://www.stackoverflow.com

executeFetchRequest returneaza un vector de rezultate pentru fiecare query dat.

Asa cum se poate observa, putem adauga NSPredicates la un fetch request pentru a tria cantitatea de date. Daca vom efectua un fetch request fara un NSPredicate atasat, vom primi toate entitatile(tabelele) inregistrate.

Update(Improspatarea bazei de date)

O intrare de update poate fi efectuata usor folosind Core Data. Trebuie doar sa executam o cautare in baza de date pentru a gasi intrarea pe care dorim sa o improspatam asa ca in blocul de cod de mai jos apoi trebuie sa schimbam atributele obiectului si apoi sa salvam folosind contextul. Sa zicem ca dorim sa schimbam toate intrarile in tabelul Person. Numele vrem sa l schimbam din Ryan in Peter. Pentru a realiza asta trebuie sa facem ca mai jos:

NSFetchRequest *fetch = [NSFetchRequest fetchRequestWithEntityName:@"Person"];

NSString *nameToGet = @"Ryan";

NSPredicate *predicate = [NSPredicate predicateWithFormat:@"name = %@", nameToGet];

[fetch setPredicate:predicate];
NSError *error = nil;

NSArray *results = [[self managedObjectContext]

executeFetchRequest:fetch error:&error];

if(results) {

NSLog(@"Entities with that name: %@", results);

for(Person *p in results) {

p.name = @”Peter”; //This will change a person’s name

// to Peter, locally

^{NSLog(@"person = %@", p);}

}

return results;

} else {

^{NSLog(@"Error: %@", error);}
Sursa cod: http://www.stackoverflow.com
Stergerea din baza de date
Pentru a sterge o intrare din baza de date, folosim metoda

deleteObject oferita de NSManagedObjectContext
_{Iata un exemplu:}

NSArray *fetchedObjects = [context executeFetchRequest:fetchRequest

_{error:&error];}

for (Person *info in fetchedObjects) { [context deleteObject:info];

_}
if (![context save:&error]) {

NSLog(@"Whoops, couldn't save: %@", [error localizedDescription]);

}

Sursa cod: http://www.stackoverflow.com
Dupa cum puteti vedea, executam un fetch request gol care ne returneaza toate intrarile de tipul Person din baza de date si apoi apelam pe toate metoda: [context deleteObject:info];
Asa cum am spus anterior, doar sa apelam metoda de stergere nu e de ajuns. Aceasta va sterge doar local intrarile si daca dam restart la aplicatie, baza de date tot va contine intrarea respectiva. Asadar trebuie sa apelam metoda [context save:&error] pentru a salva modificarile.

5. Locul Bazelor de date in MVC

In MVC, bazele de date sunt de cele mai multe ori localizate in layer-ul Model.

De exemplu daca modelul nostru descrie tranzactia de date cu valori de dolari, putem sa avem fetch request care transmit sume ale acelor valori.
Aici putem face calcule cu valorile respective si sa le transmitem mai departe la Controller unde putem si sa citim sau sa schimbam datele de input de la UI si sa improspatam display-ul cu date. Controllerele nu ar trebui sa faca mai mult decat atat.
Desigur, in cazuri extrem de complexe cu privire la logica aplicatiei, putem creea un singleton ca DerivativesTradingProfitabilityEngine care poate sa ia datele din baza noastra si sa populeze Controllerele. Acest lucru ar fi util daca avem de aface cu multe thread-uri in background.

6. Locul bazelor de date in N-tiers

In ceea ce priveste acest tip de arhitectura lucrurile sunt mai simple, baza de date trebuie sa se regaseasca pe un tier separat/o statie fizica separata, denumit Data Access Layer.

BIBLIOGRAFIE

Vandad, N. (2013) iOS 7 Programming Cookbook, California: O’Reilly.

N-Tier Architecture and Tips [Online], disponibil la adresa: www.codeproject.com

N-Tier Data Applications Overview [Online], disponibil la adresa: msdn.microsoft.com/en-us/library/
www.stackoverflow.com