Am inceput sa folosesc din plin tabelele din Windows Azure. Orice fel de date se pot salva acolo, atata timp cat sunt serializabile.
Cu ajutorul lor am facut maparea unor entitati fara probleme. Am ajuns in momentul in care intre doua entitati A si B aveam o relatie n la m, iar intre alte doua entitati 1 la n. Fara nici o problema am scris:
Greseala mea, fapta fiind deja comisa a trebuit sa caut solutii la aceasta problema. Am gasit urmatoarele solutii:
http://convective.wordpress.com/2009/12/30/entities-in-azure-tables/
In momentul acesta am de ales intre ultimele doua variante. Cred ca o sa aleg ultima varianta din cauza si altor neajunsuri pe care le are in momentul de fata Windows Azure la capitolul tabele( modul in care se genereaza un query).
Partea a 2-a: http://vunvulearadu.blogspot.com/2011/02/propietati-de-tip-array-in-tabelele-din.html
Cu ajutorul lor am facut maparea unor entitati fara probleme. Am ajuns in momentul in care intre doua entitati A si B aveam o relatie n la m, iar intre alte doua entitati 1 la n. Fara nici o problema am scris:
public List<Guid> ItemIds { get; set; }
Am continuat sa scriu codul in continuare fara nici o problema, iar intr-un final am ajuns la unit-teste unde am avut o surpriza nu tocmai placuta. Cea ce am ignorat de la bun inceput a fost faptul ca tabele din Windows Azure nu sunt O/R, ele nu stiu sa stocheze in mod default o lista.Greseala mea, fapta fiind deja comisa a trebuit sa caut solutii la aceasta problema. Am gasit urmatoarele solutii:
- o propietate de tip string care sa stocheze id-urile despartite printr-un caracter special. Solutia destul de viabila, daca tinem cont de faptul ca obiectele care se stocheaza pe tabele nu ajung sa fie folosite pe partea logica si/sau client side;
- o tabela intermediara care sa stocheze relatiile intre cele doua obiecte. Pare o solutie bunicica, dar ma sperie putin ideea de a crea aceste tabele intermediare;
- ultima solutie gasita care m-a incantat cel mai mult este prin folosirea lui DataServiceContext. Acesta ne permite sa controlam momentul in care o entitate se salveaza sau se incarca dintr-un tabel si sa modificam continutul care se salveaza.
- ReadingEntity: pentru citirea din tabel;
- WritingEntity: pentru scrierea in tabel;
http://convective.wordpress.com/2009/12/30/entities-in-azure-tables/
In momentul acesta am de ales intre ultimele doua variante. Cred ca o sa aleg ultima varianta din cauza si altor neajunsuri pe care le are in momentul de fata Windows Azure la capitolul tabele( modul in care se genereaza un query).
Partea a 2-a: http://vunvulearadu.blogspot.com/2011/02/propietati-de-tip-array-in-tabelele-din.html
Comments
Post a Comment