[es] - Linq & ORM's - everyone is invited ;)

negyxo
Aleksandar Perkuchin

Član broj: 29751
Poruke: 898
*.sksyu.net.

+171 Profil

Linq & ORM's - everyone is invited ;)

^{05.05.2007. u 15:28 - pre 206 meseci}

Pa napokon i do ove price da dodjemo. Licno, mislim da ce ova tehnologija biti interesanta za vecinu koji ovde dolaze, ako ne sama tehnologija onda bar ovaj thread, jer vecina koja dolazi na .NET foruma, po mojom proceni, radi neku vrstu data aplikacija. Uglavnom, namena LINQ nije samo manipulacija, nad nekim objektima u svetu DB-a, nego nad raznim podacima. (otprilike moglo bi se reci da se program sastoji od algoritma i podataka, ne bitno koje je namene

)

Namerno sam napisao LINQ & ORM's jer zelim da se razdvoji manipulacija od same definicije, tj. ORM scheme kakva god da je ona i u cemu god da je definisana. LINQ je, ajde da kazem podjezik (to je nesto najvise sto mozemo da ga okvalifikujemo, sudeci po prosloj temi .NET .3.5.) Ukratko ono sto se meni svidelo kod LINQ-a je nacin manipulacije nad objektima, nesto slicno kao SQL, za koji su svi ovde upoznati, samo sto je, po meni, jos mocnije (ipak manipulacija objektima i poljima nije isto). Kako LINQ radi? E to je vec prica za sebe, ja se ne bi usudio da objasnjavam, mada sam nacin rada i nije toliko komplikovan, ono sto bi mozda trebalo naglasiti da je LINQ ustvari proizvod evolucije C# jezika, sto znaci da je LINQ veoma lako prosirljiv custom funkcijama, ovo je nesto sto meni smeta kod SQL-a, tamo je politika otpriliko, 'to ti je sto ti je'

(recimo analiticke f-uje, koje ukoliko ne postoje u onom obliku koje vama treba, zbog performansi zavrsite u mix-u SQL-a i programskom delu SQL(imperativne naredbe) vaseg DB-a) Uglavnom, evo jedno lepo objasnjenje kako LINQ radi, doduse na engleskom je ali kome to danas smeta, onda, bez uvrede, mislim da mu i nije mesto u programiranju

Sve je ovo lepo ali LINQ manipulise objektima, a ako njih nema onda je sam LINQ bezvredan. Tu stupaju na scenu ORM alati.
I ovaj deo mene mnogo kopka, zato bi nastavio diskusiju sa prosle teme sa par pitanja.

Odgovor na temu

negyxo
Aleksandar Perkuchin

Član broj: 29751
Poruke: 898
*.sksyu.net.

+171 Profil

Re: Linq & ORM's - everyone is invited ;)

^{05.05.2007. u 15:34 - pre 206 meseci}

@mmix at http://www.elitesecurity.org/t258817-0#1565427

Citat:

Ono sto izdvaja linq i llblgen je mogucnost kreiranja novih entiteta kroz trasformaciju postojecih kao sto to npr radi VIEW u SQLu, ono sto meni smeta zapravo je sto je LINQ generisani model samo runtime i ogranicen na rezultat te jedne operacije i iako donosi strong typing u manipulaciju podacima, ogranicen je na scope LINQ objekata i daje samo jedan entitet po operaciji, tako da moze da se nazove OM, al tesko ORM jer mu fali relacioni deo . llblgen mi to omogucava, plus imam strong typed entitete bazirane na standardnim DataTable objektima koji mi omoguvcavaju design-time binding, i ima zaista cool ssitem predikata baziran na overloadima; ali moram da koristim externu alatku, cekam da se smiluju da implementiraju LINQ for LLBLGEN (taj si zaboravio ) i ne mogu da kroz IDE grupisem entitete u setove sto je meni vazno jer necu da pakujem svaki entitet zasebno kad treba negde da ih prebacim (a i voleo bih da imam mogucnost da CRUD prebacim sa autogenerated SQL koda na stored-procedure, sto je jos daleko a ni ADP.NET EM to nije imao u planu).

Interesuje me ovo

Citat:

LINQ generisani model samo runtime i ogranicen na rezultat te jedne operacije

Citat:

ogranicen je na scope LINQ objekata i daje samo jedan entitet po operaciji, tako da moze da se nazove OM, al tesko ORM jer mu fali relacioni deo .

Ovo mi nije jasno, moze li mali primer na sta mislis?

Odgovor na temu

logic_rabbit
Radenko Zec
banjaluka

Član broj: 74458
Poruke: 271
*.teol.net.

+1 Profil

Re: Linq & ORM's - everyone is invited ;)

^{06.05.2007. u 20:29 - pre 206 meseci}

Moze jedno pitanje?
Ako koristim Typed Dataset i dodam neku kolonu u tabeli u bazi da li moram onda ponovo generisati semu?
Znaci li to da kod svake promene u bazi moram menjati i kod aplikacije?
Ako je tako to je onda ziva glupost....

logic_rabbit (MCAD,MCSD,MCT,MCTS-
Windows development,MCPD)

Odgovor na temu

negyxo
Aleksandar Perkuchin

Član broj: 29751
Poruke: 898
*.sksyu.net.

+171 Profil

Re: Linq & ORM's - everyone is invited ;)

^{07.05.2007. u 07:24 - pre 206 meseci}

Nazalost, moras. Ali to moraju svi ORM alati, jedino sto je u nekima mozda lakse od drugih. Idealno bi bilo da se samo jednom 'jedna logika' napise na jednom mestu i to na vise mesta koristi. Nesto u fazonu 'write once, use many'

Dokle god su odvojene stvari koje po prirodi stvari ne bi trebalo da budu odvojene, radice se redudantni poslovi a samim tim i komplikovati. Zato se ja nadam da ce u buducnosti doci do izmene te logike, mislim da nas ceka nesto sto ce sve vise liciti na neuronske mreze

Recimo, ADO .NET EF ide u tom smeru, jer su najavili podrsku na samom SQL Serveru.

Odgovor na temu

mmix
Miljan Mitrović
Profesorkin muz
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6042

+4631 Profil

Re: Linq & ORM's - everyone is invited ;)

^{07.05.2007. u 14:08 - pre 206 meseci}

Citat:

negyxo: @mmix at http://www.elitesecurity.org/t258817-0#1565427
LINQ generisani model samo runtime i ogranicen na rezultat te jedne operacije i iako donosi strong typing u manipulaciju podacima, ogranicen je na scope LINQ objekata i daje samo jedan entitet po operaciji, tako da moze da se nazove OM, al tesko ORM jer mu fali relacioni deo
Ovo mi nije jasno, moze li mali primer na sta mislis?

Zato sto ne postoji nacin da deklarises design time strukturu koja ce nositi shemu rezultata LINQ operacija, cime je databinding limitaran na manuelni binding iz koda, sto je u totalnoj suprotnosti sa RAD pristupom razvoju.

Runtime shema koju dobijes kao podset LINQ operacije je anonymous type baziran na IEnumerable tipu. Taj tip zivi koliko i rezultat LINQ operacije i ne moze se prenositi van scope-a metoda koji je deklarise (npr ne mozes vratiti kao rezultat metode) jer iako mozes da kroz novi "var" feature utisnes (inferr) tip u neku promenljivu, ne mozes utisnuti tip u povratnu vrednost metoda. Zapravo, mozes vratiti tu instancu, ako se castuje u object tip, ali gubis intelisense i gubis compile-time type checking i izlazes se potencijalnim runtime greskama.
primer:

Code:

var queryResult = from customer in customers
                                where customer.OrderCount > 10
                                orderby customer.ID
                                select new { customer.ID };

// van scope-a queryResult varijable, kompiler ne zna da postoji queryResult.ID

Da bi sve to resio moras da se odreknes podsetova i da rezultate vracas u istom tipu u kome si ih koristio u kome ces rezultat dobiti kao IEnumerable<pocetnitip> pa mozes da zadrzis strong type, sto opet nije resenje ako imas velike objekte a treba ti jedno polje. Npr:

Code:

IEnumerable<Customer> queryResult = from customer in customers
                                where customer.OrderCount > 10
                                orderby customer.ID
                                select customer;

Drugo resenje je da kreiras klasu MojCustomer sa jednim propertijem ID i da koristis sledeci kod, ali ako ja treba da pisem klase za svaki LINQ podset onda tu nema leba:

Code:

IEnumerable<MojCustomer> queryResult = from customer in customers
                                where customer.OrderCount > 10
                                orderby customer.ID
                                select new MojCustomer {customer.ID };

Isto je ocigledno da svaka LINQ operacija vraca jedan entitet i samo jedan entitet. Svaki rezultat je ostrvo za sebe i ne mozes uspostaviti relaciju medju njima, zato kazem da je OM a ne ORM. Em je trebalo to da resi, da mi omoguci da kreiram vizuelno entitete kroz subclassing postojecis DB entiteta i da te tipove koristim kroz LINQ. Iako mi to ne reseava problem OM vs ORM, postoji workaround posto su tipovi rezultata isti (poticu iz EMa) uvek mogu da upucam IEnumerable<EMTip> nazad u EM model i da isforsiram relacioni deo. To ce npr biti moguce sa LINQ for DataSet, ali LINQ for dataset nema sublass mapiranje entiteta

. Nadam se da sad vidis zasto je EM trebao da bude to magicno resenje i zasto sam se iznervirao sto je odlozen. Ako Orca izadje bez EMa mogu i da ustede te programerske sate za EM i da ga ni ne prave, niko nece cekati da se oni saberu, pocece projekte sa LLBLom ili nekim drugim alatom a kad se to desi niko se nece vracati na EM kad izadje.

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ć

Odgovor na temu

negyxo
Aleksandar Perkuchin

Član broj: 29751
Poruke: 898
*.sksyu.net.

+171 Profil

Re: Linq & ORM's - everyone is invited ;)

^{11.05.2007. u 09:37 - pre 206 meseci}

Da nastavimo...
Jasno je na sta si mislio, samo bi malo razjasnio. Napisao si

Citat:

Nadam se da sad vidis zasto je EM trebao da bude to magicno resenje i zasto sam se iznervirao sto je odlozen

To me je malo bunilo. Kada se dodje do LINQ manipulacije, onda je svejedno koji je ORM alat je u pitanju. Svi pate od tog istog efekta da se ne zna schema do samog izvrsavanja upita (sem ukoliko rezultujuca schema nije ista kao pocetni entitet/i), a samim tim nista onda od designera i onog lokalnog scope.
Inace, meni se licno ne svidja LINQ to DataSets, i to iz jednog razloga, problem je sto moras unapred da ucitas podatke u DataSet, a i to ucitavanje kako god da uradis znaci da ce se uvek ucitavati istom metodom (naravno moze i druga metoda, ali tek to je onda igranje) a samim tim dolazi se i do efekta 'bespotrebnih podataka' jer, recimo, neki DataAdapter u Fill metodi moze imati nesto poput ovoga u SQL-u:

Code:

SELECT [EmployeeID]
      ,[LastName]
      ,[FirstName]
      ,[Title]
      ,[TitleOfCourtesy]
      ,[BirthDate]
      ,[HireDate]
      ,[Address]
      ,[City]
      ,[Region]
      ,[PostalCode]
      ,[Country]
      ,[HomePhone]
      ,[Extension]
      ,[Photo]
      ,[Notes]
      ,[ReportsTo]
      ,[PhotoPath]
  FROM [Northwind].[dbo].[Employees]

Koja ce popuniti DataTabelu sa identicnim poljima, ali ako ja zelim samo

Code:

var q = from c in db.Customers
select new {c.ContactName, c.Address};

Ce se prevesti u SQL preko DLINQ-a

Code:

SELECT [t0].[ContactName], [t0].[Address]
FROM [Customers] AS [t0]

ili EF

Code:

SELECT
[Extent1].[ContactName] AS [ContactName],
[Extent1].[Address] AS [Address]
FROM [dbo].[Customers] AS [Extent1]

Uglavnom, i po meni EF, ima najvise smisla da zazivi jer omogucuje veci nivo abstrakcije, tj. beskonacan nivo abstrakcije

(nadam se da moze da se kreira entitet na osnovu entiteta a ne samo na osnovu donjeg sloja - relacionog). Pored ovoga se nadam da ce neko uvideti da je manipulacija preko LINQ kljucna stvar, i da ce naici podrska na SQL Serveru, jer ja zelim da imam strong type checking po svaku cenu i build opciju nesto u fazonu validacija modela. Da mi se ne desava kao sad, ispravim, dodam, nesto u tabeli i bog te veseli... trazi s cim je ko vezan u bazi i na koga sve to ima uticaja. Zato se nadam da ce LINQ da nam omoguci kvalitetniju i bolju manipulaciju podataka, ali se plasim da ovo ne ostane sve u domenu lose implementacije i na kraju zavrsi kao lose projektovana tehnologija.

Odgovor na temu