Nema tu neke mudrosti, ako je objekat vezan na Country tabelu, imaces efektivno dva polja (pod uslovom da si ih deklarisao u objektu ili si klasu objekta definisao kroz dbml fajl), i onda objekat mozes da vezes na Country na dva nacina,
objekat.CountryId = <postojeci id zemlje> pod uslovom da je COuntryId kljuc
ili
objekat.Country = instanca Country objekta koji si ili kreirao nov ili ucitao iz context-a
Citat:
Mikelly: E sad me interesuje LINQ to SQL, bar dok ne dodje ADO.NET Entity Framework i LINQ to ENTITIES. Najvise me interesuje kako da radim DATA BINDING. Jer, sve one klase koje generise O/R Designer izlazu samo dva dogadjaja: property changing i property changed (i cini mi se da u property changing dogadjaju ne mogu da vidim koji se property mijenja). Sto ja treba da radim, da punim sve sto procitam u neki BindingSource? A kako da izvedem parent-child prikaze? Mogu vala napunit novi BindingSource child zapisima, ali kako da povezem dva BindingSource-a?
Ne moras da vezujes dva binding source-a, oni podrzavaju hijerarhijske liste sto LINQ entiteti jesu. Npr u njegovom primeru, Country tabela je vezana za City tabelu, kad izvrsis:
var countries = from c in db.Country select c;
bindingSource.DataSource = countries;
izvrsio si bindovanje i svaki element iz countries ima property Cities koji je IQueryable interfejs koji ucitava gradove koji su vezani za tu zemlju. Naravno svako referenciranje Cities propertija ce izazvati po jedan SQL select u bazu pa je u ovim slucajevima mozda pametnije pre-loadovati sve child entitete cime ce se smanjiti broj SQL skripti koje se izvrse
Code:
DataLoadOptions lo = new DataLoadOptions();
lo.LoadWith<Country>(c => c.Cities);
db.LoadOptions = lo;
var countries = from c in db.Country select c;
bindingSource.DataSource = countries;
Ako bindovani element podrzava hijearhijske liste imaces multi-level prikaz. Fora je jedino sto je binding malo otezan iz samog dizajnera posto je binding dialog u visual studiu malo glup pa ne vidi nista dublje od prvog nivoa, a ni same fabricke kontrole nisu nista mudrije ukljucujuci tu i grid kontrolu. Ja npr koristim Infragistics grid koji to podrzava i dobijam rezulate lepo hijerarhijski:
jedino sto za sada fali je cross-table mapping sto ce valjda da resi taj Entity Framework, al otom potom. Ako bas hoces mozes vec sad da iskoristi LINQ for objects preko LLBLGen generisanih entiteta.
Citat:
Mikelly: LINQ to SQL je ok, zapisi su objekti, prirodnije je i lakse radit s njima, mada su i tipizirani dataset-ovi standardnog ado.net-a imali neke takve karakteristike, ali mu fali sva sila stvari sto su imali datarow i datatable objekti. Ne znam, na prvi pogled mi se cini da je istu stvar mnogo lakse izvesti u ado.net-u nego koriscenjem LINQ to SQL-a (mada vjerovatno, ili prije sigurno to mu nije ni namjena, vec samo da eliminise SQL upite iz aplikacije).
LINQ for SQL zapravo olaksava DataSet operacije jer ne moras da generises table adaptere za svaku mogucu primenu koja ti treba, pride nisi mogao da ucitas samo podset polja, datatable ce uvek imati ona polja koja su definisana u tipiziranom datasetu cak iako ih ne ucitas kroz Query (ako uopste i uspes u tome, npr ne mozes preskociti polje iz tabele koje je NON NULL i nema default vrednost). Zamisli da je LINQ runtime dataset generator koji odmah generise tipiziranu tabelu i query koji je popunjava.
Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić
LINQ to SQL - razna pitanja
Re: LINQ to SQL - razna pitanja
