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 :)
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...?
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 ;) ?
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:)
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....
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.
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 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.
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:)
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.
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.
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. :)
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).
Riješio :) Nestani upiti tj. chained :)
Zgodno. I dalje mi se čini da LINQ efektivno rješava CRUD. Vidjet ćemo u praksi.
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!
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."
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)
Viteže a kako bi ti to riješio? Osim toga, elegantnije je to riješiti u kôdu nego SQL-u:)
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".
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.
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.
Š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 ...
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.
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.
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
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)?
...
?
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.
Za sada i ja radim tako, gdje se sa DALom komunicira preko provider layera i interfacea, pa razmisljam sto bi dobio sa Entity Frameworkom...
Za sada i ja radim tako, gdje se sa DALom komunicira preko provider layera i interfacea, pa razmisljam sto bi dobio sa Entity Frameworkom...
