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
0 comments:
Post a Comment