To LINQ or !to LINQ

poruka: 59
|
čitano: 11.776
|
moderatori: Lazarus Long, XXX-Man, vincimus
+/- sve poruke
ravni prikaz
starije poruke gore
13 godina
neaktivan
offline
RE: To LINQ or !to LINQ

Jako zgodan feature za pretraživanje collection objekta. Skraćuje kod, no nisam imao priliku isprobati ga u nekoj jačoj aplikaciji da usporedim performanse u odnosu na klasični pristup pretraživanja objekata.

 

Javim ti za koji tjedan da li sam zadovoljan :)


www.cartmanlee.net
 
0 0 hvala 0
13 godina
neaktivan
offline
RE: To LINQ or !to LINQ

Ja sam primijetio da je nešto sporiji (mislim da još postoje mjerenja online), negdje oko 28% od klasičnog ADO.NET-a kod pristupa bazi. Nadam se da su performanse popravili od tog vremena (testiranje se vršilo na Beti).

Čitao sam i o nekim problemima, pa me zanimalo koliko je strah od korištenja takve stvari u produkciji opravdan. ORM-ove ljudi koriste godinama, ali pitanje je koliko je LINQ prikladan za stvarnu upotrebu u tom segmentu.

XML dio po mojim saznanjima olakšava kodiranje poprilično, ali verzija u konekciji s RDBMS-ima...?

Poruka je uređivana zadnji put uto 12.2.2008 8:51 (naxeem).
13 godina
neaktivan
offline
RE: To LINQ or !to LINQ

Naxeem, može neki link na ta mjerenja. Ovo što si rekao stoji, ali ne mislim ga koristiti za pristup bazi, samo za pretragu po kolekcijama. Ako ADO.NET uredno šljaka, koji ću vrag koristiti nešto drugo ;) ?


www.cartmanlee.net
13 godina
neaktivan
offline
RE: To LINQ or !to LINQ

Mjerenja: http://alexpinsker.blogspot.com/2007/07/benchmarking-linq-vs.html

 

ADO.NET uredno šljaka, ali za napisati svo to smeće od kôda čovjek se samo iznervira:)

13 godina
offline
To LINQ or !to LINQ

Malo sam ga testirao i odmah mi se svidio. Kao O/R mapper jednostavniji za koristenje od npr. NHibernatea, integrisan je u VS, iza njega stoji MS itd...

Medjutim kada je u pitanju stvar zbog koje ga posebno hvale - i po cemu je dobio i naziv - a to je integracija u jezik, provjera sintakse prilikom kompajliranja itd...tu pada na jednom vrlo cestom zahtjevu: dinamicka konstrukcija upita. Microsoft je izdao neke primjere u kojima se vidi kako se to moze izvesti - ali baratanjem uslovima upita kao stringovima - sto je samo po sebi suprotno ideji LINQ-a.

 

Drugi problem je sto MS ove godine planira izdati ADO.NET Entity Framework, koji bi trebao biti puno napredniji, rijesiti neke probleme LINQ-a, kao sto je ogranicenost u nacinima mapiranja klasa na tabele, podrska za druge DBMS-ove, itd... Koliko ce to sve imati veze s LINQ-om i koliko se isti isplati poceti koristiti LINQ sada, ne znam....

 
0 0 hvala 0
13 godina
neaktivan
offline
RE: To LINQ or !to LINQ

Mene zato i zanima: ići na nešto poput NHibernatea ili na LINQ? Konkretno za projekte koji baš startaju. ADO.NET CRUD kôd jednostavno je neisplativ. Kao čisti ORM može li LINQ pružiti barem jednako kao NHibernate? Ako može, ne vidim razlog zašto ne ići Microsoft way u tom slučaju.

Doduše, dinamički upiti i jesu ono što je najveći problem ADO.NET-a: izrazito ružan i trapav kôd. Ako LINQ ide barem stepenicu naprijed mislim da je dobar izbor makar to ne bilo u dugu LINQ-a.

13 godina
offline
RE: To LINQ or !to LINQ

Ne znam jesmo li se razumjeli najbolje po pitanju dinamicke konstrukcije upita...

Mislio sam na to da, npr. imas preglednu formu sa proizvoljnim brojem parametara.

 

Onda napravis mehanizam koji ti daje mogucnost da napises negdje (bilo gdje, u file npr.)  osnovni SQL upit bez parametara - a onda iz liste parametara (ovisno o tome sta je korisnik unio) izgenerises "WHERE" uslov, ali po nekom mehanizmu koji moze raditi za sve upite i za proizvoljan broj parametara.

To se najcesce radi konkatenacijom stringova ("WHERE [ColumnName1] = [@ParamName1] AND [ColumnName2] = [@ParamName2] AND "....itd... dok ne izgenerise WHERE za sve proslijedjene parametre (naravno, nisam mislio i na konkatenaciju vrijednost parametara, sto mozes vidjeti iz "@"). Medjutim, kod LINQ-a WHERE nije string, nego je dio jezika, tako da se to ne moze raditi - osim ako se koristi opet na taj gore pomenuti microsoft nacin - sto LINQ where opet pretvara u string - a samim time to vise nije LINQ.

 

Mislim da LINQ jos nema sve mogucnosti NHibernate-a, ali da je vrlo blizu tako da mislim da se isplati zapoceti s njim, ali to konkretno moras vidjeti na svom projektu i njegovim potrebama.

 

A ADO.NET za CRUD je mislim najgore rjesenje - tako da svakako biraj LINQ ili NHibernate, pogotovo ako imas pravi objektni model na business sloju.

13 godina
online
RE: To LINQ or !to LINQ
knight kaže...

Ne znam jesmo li se razumjeli najbolje po pitanju dinamicke konstrukcije upita...

Mislio sam na to da, npr. imas preglednu formu sa proizvoljnim brojem parametara.

 

Onda napravis mehanizam koji ti daje mogucnost da napises negdje (bilo gdje, u file npr.)  osnovni SQL upit bez parametara - a onda iz liste parametara (ovisno o tome sta je korisnik unio) izgenerises "WHERE" uslov, ali po nekom mehanizmu koji moze raditi za sve upite i za proizvoljan broj parametara.

To se najcesce radi konkatenacijom stringova ("WHERE [ColumnName1] = [@ParamName1] AND [ColumnName2] = [@ParamName2] AND "....itd... dok ne izgenerise WHERE za sve proslijedjene parametre (naravno, nisam mislio i na konkatenaciju vrijednost parametara, sto mozes vidjeti iz "@"). Medjutim, kod LINQ-a WHERE nije string, nego je dio jezika, tako da se to ne moze raditi - osim ako se koristi opet na taj gore pomenuti microsoft nacin - sto LINQ where opet pretvara u string - a samim time to vise nije LINQ.

 

Mislim da LINQ jos nema sve mogucnosti NHibernate-a, ali da je vrlo blizu tako da mislim da se isplati zapoceti s njim, ali to konkretno moras vidjeti na svom projektu i njegovim potrebama.

 

A ADO.NET za CRUD je mislim najgore rjesenje - tako da svakako biraj LINQ ili NHibernate, pogotovo ako imas pravi objektni model na business sloju.


Ne treba mjesati kruske i jabuke, LINQ je query engine koji radi i na nHibernateu (ili ce brzo - neznam u kojoj su fazi implementacije!), DLINQ odnosno LINQ to SQL je code generator klasa (IEnumerable i IQueryable) koje mapiraju tablice u bazi.
nHibernate se moze eventualno usporediti sa Entity Frameworkom, iako sumnjam da ce Entity F. imati onakvu gomilu proxy i service providera kao sto ima nHibernate.

Cilj MSa je da se LINQ2SQL koristi za jednostavnije projekte, a Entity Framework (izgleda mi kao nasljednik napustenog ObjectSpacesa) je kao namjenjen za enterprise rijesenja, i kao takav se nadovezuje na LINQ. Glavna prednost Entitya je sto konceptualni model klasa ne mora reprezentirat fizicki relacijski model u bazi - znaci u EF vi definirate vlastite klase sa nasljedzivanjima, interfaceovima i kojecim, i preko EF Designera te klase mapirate na razlicite tablice u bazi.
U usporedbi s time, cini mi se da nHibernate pokriva jos neka podrucja proxy providera i sl. koja EF nema.

Inace, nHibernate je odlican ako se zna raditi s njime (XML konfiguriranje...) i dosta je komplexan. Jednostavnija, light verzije NH-a je ActiveRecords kojemu je baza NH i doboljan je za 95% stvari.

Jos treba spomenuti vjerojatno najbolji OR/M alat llblGen, koji se placa, te NetTiers koji je dosta slican NH-u.

#define QUESTION ((bb) || !(bb))
13 godina
online
To LINQ or !to LINQ

Zaboravio sam napomenuti glede perfomansi - kako svi OR/M alati interno rade sa ADO.NETom odnosno dataReaderima, svi su sporiji od njega (stvar apstrakcije). Vise je problem dali alat koristi reflexije ili ne - svi ovi OR mapperi su u osnovi code generatori samo da bi izbjegli reflexije (i bili strong typed naravno).

 

Ali generalno gledano, najbrzi je rucni ADO.NET i najdulji za piskarat, iza njega su nhibernate i netTiers, tu negdje je i LINQ ako se znaju dobro pisati upiti i pratiti SQL Profiler, a najsporiji je rad sa DataSetovima (koje treba zabraniti:)


#define QUESTION ((bb) || !(bb))
Moj PC  
0 0 hvala 0
13 godina
offline
To LINQ or !to LINQ

Ne treba mjesati kruske i jabuke, LINQ je query engine koji radi i na nHibernateu (ili ce brzo - neznam u kojoj su fazi implementacije!), DLINQ odnosno LINQ to SQL je code generator klasa (IEnumerable i IQueryable) koje mapiraju tablice u bazi.


Ma cijela moja prica se odnosila na LINQ to SQL, ali nisam to posebno napominjao, posto to i jeste dio LINQ-a koji me najvise zanima. A mislim da LINQ to SQL nije prosto code generator klasa, nego je on LINQ na klase koje su mapirane na bazu - dakle kompletan engine za perzistenciju objekata upite nad njima (a klase mozes napisati i rucno).

(LINQ to SQL provides a runtime infrastructure for managing relational data as objects without losing the ability to query. Your application is free to manipulate the objects while LINQ to SQL stays in the background tracking your changes automatically.)


Zaboravio sam napomenuti glede perfomansi - kako svi OR/M alati interno rade sa ADO.NETom odnosno dataReaderima, svi su sporiji od njega (stvar apstrakcije).
Vise je problem dali alat koristi reflexije ili ne - svi ovi OR mapperi su u osnovi code generatori samo da bi izbjegli reflexije (i bili strong typed naravno).


Ovo te ne kontam? NHibernate koristi refleksiju (doduse, ne konstantno, jer pravi proxy klase na startupu) (a HQL nije strong typed), a mislim i LINQ to SQL da radi preko refleksije (bilo atributi ili mapping fajlovi).
A vezano za usporenje koje dobijes zbog toga sto oni interno koriste ADO.NET  pa su samim time jedan nivo apstrakcije izmedju naseg koda  - ne bih se slozio. U svakom slucaju ti moras napisati ili svoj kod da perzista neki objekat, ili ces taj objekat proslijediti NHIbernate-u, koji ce koristiti refleksiju i mapping fajlove da perzista isti - tako da se svede na to da je samo refleksija razlog usporenja.

Poruka je uređivana zadnji put uto 12.2.2008 13:53 (knight).
 
0 0 hvala 0
13 godina
neaktivan
offline
To LINQ or !to LINQ

Ja inače sve radim na principu: SP + DAL metoda + BLL metoda + PLL. Dakle, ADO.NET učitavanje podataka (u 90% slučajeva iz procedure), mapiranje parametara u naredbu, izvođenje, parsanje readera u neku custom kolekciju (najčešće List<T>) i proslijeđivanje kolekcije BLL-u od kojeg to uzima sama prezentacija (dakle repeater npr.).

Ono što je tu dobro je apsolutna kontrola nad kôdom i onime što se radi. Međutim pisanje mapiranja parametara u C# objekte/tipove i prebacivanje u upotrebljive kolekcije je moja noćna mora. Užasan gubitak vremena, error prone itd.

 

Da, čuo sam za NetTiers ali me količina smeća koje generira jednostavno dobija. NHibernate hvali jedan kolega i tek je počeo s njime, a ja imam praktički tekući projekt za čiju se izvedbu DAL-a moram odlučiti jučer.

Problemi koje LINQ 2 SQL može imati kao što su spori queriji i sl. mogu se desiti svakom ORM-u jer ne postoji način da ORM misli za nas.

 

Ono za što meni LINQ izgleda najprivlačniji su najviše dinamički queriji tipa:

 

select x from korisnici where plaća > iznosPlaćeMin and plaća < iznosPlaćeMax

 

(kôd je pseudo, ne referiram direktno LINQ sintaksu)

 

Dakle, može li to LINQ? - Jer raditi spajanje stringova i zamorne i očajne swtcheve i ifove i slično ne želim opet ako ne moram, a nadao sam se da je LINQ upravo ono što mi treba da bih mogao jednostavno ubaciti kôd u query.

 

 

Moj PC  
0 0 hvala 0
13 godina
offline
To LINQ or !to LINQ

Ono za što meni LINQ izgleda najprivlačniji su najviše dinamički queriji tipa:

select x from korisnici where plaća > iznosPlaćeMin and plaća < iznosPlaćeMax

 

(kôd je pseudo, ne referiram direktno LINQ sintaksu)Dakle, može li to LINQ? - Jer raditi spajanje stringova i zamorne i očajne swtcheve i ifove i slično ne želim opet ako ne moram, a nadao sam se da je LINQ upravo ono što mi treba da bih mogao jednostavno ubaciti kôd u query.

 

Ako sam te dobro skontao...odgovor je mozes.

Ali opet - pitanje je, sta ako zelis da mozes pretrazivati sve korisnike

a) sa platom vecom od <vrijednost>

b)  sa platom manjom od <vrijednost>

c) sa placom vecom od <vrijednost1> AND manjom od <vrijednost2>

 

 

Pisaces tri upita u LINQ? Ne, hvala. Pogotovo ako je upit kompliciraniji i sadrzi veci broj parametara (npr. zelis korisniku na formi omoguciti da definise broj uslova, ili da selektivno popuni odredjenu formu sa svim uslovima - sto je sasvim uobicajena potreba). Sto veci broj parametara vise kombinacija.

 

Ili ces osnovni dio napisati u LINQ-u, a uslov konstruisati spajanjem stringova pa ga (nekako, ne znam tacan nacin) predati osnovnom upitu u LINQ-u (to je ono sto MS predlaze).

Medjutim, tad imas polu-strongly-typed LINQ.

 

A spajanje stringova kod klasicnog SQL-a uopste ne podrazumijeva if-ove i switcheve - moguce je napraviti relativno jednostavan i inteligentan mehanizam kome proslijedis osnovni upit plus listu uslova, i on izgenerise kompletan upit, plus listu DbParametara za DbCommand (a da uopste taj mehanizam nema veze sa konkretnim upitom i parametrima, vec radi za bilo koje). Napomena: ovdje ne govorim SP, nego CommandType.Text. :)

 

 

 

 

Poruka je uređivana zadnji put uto 12.2.2008 15:22 (knight).
 
0 0 hvala 0
13 godina
neaktivan
offline
RE: To LINQ or !to LINQ
knight kaže...

Ono za što meni LINQ izgleda najprivlačniji su najviše dinamički queriji tipa:

select x from korisnici where plaća > iznosPlaćeMin and plaća < iznosPlaćeMax

 

(kôd je pseudo, ne referiram direktno LINQ sintaksu)Dakle, može li to LINQ? - Jer raditi spajanje stringova i zamorne i očajne swtcheve i ifove i slično ne želim opet ako ne moram, a nadao sam se da je LINQ upravo ono što mi treba da bih mogao jednostavno ubaciti kôd u query.

 

Ako sam te dobro skontao...odgovor je mozes.

Ali opet - pitanje je, sta ako zelis da mozes pretrazivati sve korisnike

a) sa platom vecom od <vrijednost>

b)  sa platom manjom od <vrijednost>

c) sa placom vecom od <vrijednost1> AND manjom od <vrijednost2>

 

 

Pisaces tri upita u LINQ? Ne, hvala. Pogotovo ako je upit kompliciraniji i sadrzi veci broj parametara (npr. zelis korisniku na formi omoguciti da definise broj uslova, ili da selektivno popuni odredjenu formu sa svim uslovima - sto je sasvim uobicajena potreba). Sto veci broj parametara vise kombinacija.

 

Ili ces osnovni dio napisati u LINQ-u, a uslov konstruisati spajanjem stringova pa ga (nekako, ne znam tacan nacin) predati osnovnom upitu u LINQ-u (to je ono sto MS predlaze).

Medjutim, tad imas polu-strongly-typed LINQ.

 

A spajanje stringova kod klasicnog SQL-a uopste ne podrazumijeva if-ove i switcheve - moguce je napraviti relativno jednostavan i inteligentan mehanizam kome proslijedis osnovni upit plus listu uslova, i on izgenerise kompletan upit, plus listu DbParametara za DbCommand (a da uopste taj mehanizam nema veze sa konkretnim upitom i parametrima, vec radi za bilo koje).

 

 

 

 

 Ajmo na konkretan primjer:

imam tablicu: Zaposlenici : { ime, plaća, radnidani, bojakose }

i sad želim pretraživati: po iznosu plaće (od - do), po broju radnih dana ali na način da želim da (iz dropdown menija) odaberem 1-10 radnih dana, a ako odaberem 10 da mi prikaže i sve  unose i manje i veće od 10, i da biram boju kose, ako odaberem boju od 1-3 da izvuče samo tu boju, a ako odaberem 0 da izvuče sve boje.

Eto, zanima me kako bi to LINQ riješio. U klasičnom ADO.NET sistemu ovakvu stvar moram rješavati tako da ispitujem svaku od opcija prvo u kodu, a onda za svaku mogućnost imam poseban SQL query.

pseudo kod:

if( radnidani > 1 && radnidani < 10) query = "select * from zaposlenici where .... radnidani = " + rd.ToString() + "...";
    if(bojakose > 1 && bojakose < 3) query +" AND bojakose = " + bk.ToString() + " ...";
    else query +" ";
else
....

Vrlo nepraktično i naporno.

Hvala :)
Poruka je uređivana zadnji put uto 12.2.2008 15:39 (naxeem).
13 godina
neaktivan
offline
To LINQ or !to LINQ

Riješio :) Nestani upiti tj. chained :)

 

Zgodno. I dalje mi se čini da LINQ efektivno rješava CRUD. Vidjet ćemo u praksi.

Moj PC  
0 0 hvala 0
13 godina
online
RE: To LINQ or !to LINQ
naxeem kaže...

Eto, zanima me kako bi to LINQ riješio. U klasičnom ADO.NET sistemu ovakvu stvar moram rješavati tako da ispitujem svaku od opcija prvo u kodu, a onda za svaku mogućnost imam poseban SQL query.

pseudo kod:

if( radnidani > 1 && radnidani < 10) query = "select * from zaposlenici where .... radnidani = " + rd.ToString() + "...";
    if(bojakose > 1 && bojakose < 3) query +" AND bojakose = " + bk.ToString() + " ...";
    else query +" ";
else
....

Vrlo nepraktično i naporno.

Hvala :)
 

Za to LINQ ima Dynamic Query Language, s kojim se isto slaze query sa stringovima, kao i u HQLu i EF query jeziku. Ali takve stvari opcenito treba izbjegavati zbog samog cacheiranja execution plana unutar sql servera i sl.


#define QUESTION ((bb) || !(bb))
13 godina
online
To LINQ or !to LINQ

Po meni je LINQ2SQL odlicna stvar zvog query engina, a sve ove "pametne" stvari poput pracenja objekata i dataContext.SubmitChanges() fore treba wrapat u posebni provider.

 

I treba biti oprezan za deferedLoad (lazy load) svojstvom, jerbo se meni desilo da je prilikom slanja kolekcije objekata preko web servisa ovaj potegnuo iz baze i vezane objekte. Naprimjer ja sam htio poslati Customere, a ovaj je automatski dohvatio ih baze i sve njihove Ordere, samo zato jer je klasa za JSON serijalizaciju provjeravala koje propertije moze serijalizirati!

 


#define QUESTION ((bb) || !(bb))
Moj PC  
0 0 hvala 0
13 godina
offline
RE: To LINQ or !to LINQ

Da ne mijesamo babe i zabe... :)

Ne postoji Dynamic Query Language, Microsoft isporucuje Dynamic Query Library, koja kao takva nije dio jezika (dolazi uz LINQ samples).

A stvari kao sto je dinamicko konstruisanje upita ne treba izbjegavati, razloga za izbjegavanje stored procedura je mnogo vise nego sto je prednosti kao kesiranje execution plana na serveru.

Ovdje su navedeni neke lose strane SP: http://www.tonymarston.net/php-mysql/stored-procedures-are-evil.html

I kako rekoh, u obicnom SQL-u se te stvari mogu izvesti mnogo bolje i elegantnije od toga da " ispitujem svaku od opcija prvo u kodu, a onda za svaku mogućnost imam poseban SQL query."

Poruka je uređivana zadnji put sri 13.2.2008 10:09 (knight).
13 godina
offline
RE: To LINQ or !to LINQ

To je problem i sa lazy load kod nhibernate-a i generalno - ali u osnovi nije problem lazy load svojstva, nego nepazljive upotrebe istog - u biti lazy load radi tacno ono onako kako je i definisan. Ako pristupis property-u (kolekciji u ovom slucaju) - kolekcija ce biti inicijalizirana. A ako definises taj property kao serijalizabilan - serijalizacija ce biti okidac za loadanje. To se moze izbjeci na odredjene nacine (da serijalizaciju implementiras na neki custom nacin) - pa da mozes definisati prethodno kad zelis da budu serijalizirane i kolekcije na objektu, a kada ne (u slucaju kada saljes listu osnovnih objekata, vjerovatno neces zeljeti da se serijaliziraju i pod-kolekcije, ali ako saljes jednog Customera, vrlo vjerovatno ces zeljeti isporucivati i Orders)

13 godina
neaktivan
offline
RE: To LINQ or !to LINQ

Viteže a kako bi ti to riješio? Osim toga, elegantnije je to riješiti u kôdu nego SQL-u:)

13 godina
offline
RE: To LINQ or !to LINQ

Uglavnom koristim sljedeci fazon (nije savrseno, ali za vecinu mojih potreba pokazalo se dovoljno):

SELECT C1 As Column1, C2 AS Column2 FROM ...

U sklopu njega radim razne joine, i sve sto mi treba u normalnom upitu.


Potrebno je imati mehanizam da sa GUI-a (ili bilo kako drugo) se proslijedi array uslova za pretragu (bilo u nekim objektima neke klase Criteria(name, criteria, value), bilo na neki drugi nacin. Sta ce biti dodano u taj array zavisi od konkretnog pretrazivanja.

Zatim pozovem DAL klasu koja je zaduzena za izvrsavanje i rad s upitima (uglavnom je to vise klasa, jedna koja konstruise SQLData objekat (sadrzi kompletan query, listu SQL Parametara, order columns i), jedna koja izvrsava query (otvara konekciju, pravi Command objekat i sl ) itd...
Pozovem glavnu klasu (izvrsilac upita) i proslijedim: implementaciju osnovnog upita, array uslova i dataset.
Ta klasa uzme osnovni upit, iz arraya sa kriterijima izgradi WHERE, na sljedeci nacin
SELECT Column1, Column2...
FROM
(
OSNOVNI_UPIT
)
WHERE [ovdje izgenerise proizvoljan broj uslova - ovisno o proslijedjenim parametrima]

Zatim izgenerise Array konkretnih DB Parametara, takodje iz one liste proslijedjenih uslova.
To je otprilike to - taj mehanizam nije bas simple za objasniti ovako, ali je dovoljno dovoljno reusabilan i moze se koristiti na vise upita/projekata.
Ako se i pojavi neki slucaj u kom ne zadovoljava, onda ili unaprijedim mehanizam ako je moguce, ili to rijesim kao "specijalni slucaj".




13 godina
neaktivan
offline
To LINQ or !to LINQ

LINQ je ok ali ne volim koristiti tehnologiju koja je vezana (bar za sada) na samo jednu bazu (SQL). Pošto pravim aplikacije koje su database independent linq mi je beskoristan. Doduše mogu ga koristiti za queranje objekta ali mi je jednostavnije napisati svoje klase koje to odrađuju.

 

Preporučio bi  eXpress Persistent Objects od DeveloperExpress-a, Koi iako je još u bezi (time i besplatan), jako je jednostavan za korištenje , podržava mnogo baza i jako je moćan.

mana mu je šta kad izađe iz Bete neče bit besplatan.

 

 

 

 

 

 

 

 
0 0 hvala 0
13 godina
neaktivan
offline
RE: To LINQ or !to LINQ

Ja se trenutno vežem za SQLServer, a Oracle ne diram (iako će se možda koristiti u cjelokupnom rješenju, ali to će raditi drugi).

Ono što se meni sviđa u LINQ-u je i List.Find(I => I.Foo == 3); jer LINQ nije all about SQL.

 

Upravo ovih dana provodim testiranja LINQ-a nad realnim podacima. Za sada mi se čini da prednosti koje daje u odnosu na gubitak na performansama imaju prevagu. Za sada. Vidjet ću kad testiram sve moguće situacije.


Frankly, my dear, I don't give a damn.
13 godina
online
To LINQ or !to LINQ

Što više gledam taj LINQ i koristim ga u malim projektima, uvidzam njegovu kompleksnost a s time i snagu u primjeni na vecim rijesenjima. Znaci, knjigu u ruke i citat, citat i testirat. Moze on svasta ...


#define QUESTION ((bb) || !(bb))
Moj PC  
0 0 hvala 0
13 godina
neaktivan
offline
To LINQ or !to LINQ

Jedno od rešenja za generisanje dinamičkih upita u LINQu je Predicate Builder. U pitanju je relativno kratka statička klasa koja nudi dve metode (And i Or) pomoću kojih se dinamički kreira proizvoljan and/or predikat.

Primer metode koja pretražuje proizvode za prosleđeni niz ključnih reči:

 

IQueryable<Product> SearchProducts (params string[] keywords)
{
  var predicate = PredicateBuilder.False<Product>();

   foreach (string keyword in keywords)
   {
     string temp = keyword;
     predicate = predicate.Or (p => p.Description.Contains (temp));
   }
   return dataContext.Products.Where (predicate);
}


Rešenje je vrlo elegantno. Mislim da je jasno da će biti potrebno određeno vreme da svi skupa kolektivno promenimo način pristupa rešavanju problema. C# u verziji 3.5 sadrži već dovoljno elemenata
funkcionalno-deklarativnog stila programiranja (lambda funkcije, LINQ, ...) koji je nesumnjivo superioran u odnosu na stari imperativni pristup, ali zahteva određeno vreme navikavanja.
Moja dosadašnja iskustva sa LINQom su vrlo pozitivna. Ipak, još uvek mi se dešava da otkrijem kako se neka metoda pisana pre 20-ak dana može optimizovati sa 20 na 5 linija LINQ koda. Svaki put kada
mi se to desi setim se svojih početaka sa Transact-SQLom, trostrukih ugneždenih SELECT upita koji su savršeno radili, ali već na prvi pogled nisu izgledali lepo. Ista stvar je i sa LINQ-om, biće
potrebno određeno vreme da izučimo sve naredbe, finese, skrivene opcije...

Za one koji tek kreću sa učenjem, LINQPad je odličan alat.

Poruka je uređivana zadnji put čet 21.2.2008 9:18 (Dejan).
 
0 0 hvala 0
13 godina
neaktivan
offline
To LINQ or !to LINQ

Da se navežen na prvih par postova, LINQ je malo sporiji ali zato puno lakši i ne treba se **bat sa mapiranjem. Naravno LINQ to SQL.

 
0 0 hvala 0
13 godina
offline
RE: To LINQ or !to LINQ

Uh, za trenutak sam pomislio da se priča o

 

http://en.wikipedia.org/wiki/LINC_4GL

 

i mašio se pištolja, al srećom radi se o nečem drugom

 

13 godina
online
To LINQ or !to LINQ

Da malo probam oziviti temu:

 

tko se igrao sa Entity frameworkom i kakva su iskustva? Kako funkcionira ona famozna fora da klase ne moraju reprezentirati tablice i relacije u bazi, nego mogu zadovoljavati objektni model problema, i mapirati se na razlicite tablice (tipa jedna klasa se mapira na nekoliko tablica)?

Dali se moze koristit LINQ upiti, ili se mora pisat onaj njegov query lang unutar stringa (kao hbml u nHibernateu)?

...

?


#define QUESTION ((bb) || !(bb))
Moj PC  
0 0 hvala 0
13 godina
neaktivan
offline
RE: To LINQ or !to LINQ

Ja nisam. Za sada LINQ koristim kao DAL koji opet iznad sebe ima BLL u kojem mi se nalazi logička reprezentacija podataka koju dobijem LINQ querijima. Praktički sam samo izbacio low-level dio komunikacije direktno sa SQL Serverom.


Entrepreneurs are simply those who understand that there is little difference between obstacle and opportunity and are able to turn both to their advantage.
13 godina
online
To LINQ or !to LINQ

Za sada i ja radim tako, gdje se sa DALom komunicira preko provider layera i interfacea, pa razmisljam sto bi dobio sa Entity Frameworkom...


#define QUESTION ((bb) || !(bb))
Moj PC  
0 0 hvala 0
13 godina
neaktivan
offline
RE: To LINQ or !to LINQ
hudo kaže...

Za sada i ja radim tako, gdje se sa DALom komunicira preko provider layera i interfacea, pa razmisljam sto bi dobio sa Entity Frameworkom...


 Ne znam; vjerojatno malo širi DAL gdje više nebi imao potrebe generirati dio BLL-a. Doduše, meni osobno se čini da mi 'slobodniji' pristup generiranju objekata nebi previše olakšao, zato što ja često finalne objekte kreiram poprilično kompleksno provlačeći ih kroz nekoliko metoda. Npr. setove inputa za kalendare kreiram na način da radim nekoliko preklapanja i filtriranja.
Mislim da je jedna od većih prednosti EF-a što neće biti vezan samo za SQL Server. Kako trenutno koristim samo njega, ni ne vidim tu prednost kao meni važnu.

Entrepreneurs are simply those who understand that there is little difference between obstacle and opportunity and are able to turn both to their advantage.
Nova poruka
E-mail:
Lozinka:
 
vrh stranice