Ok, za pocetak neke stvari. IQueryable<T> nad EF objektom je ObjectQuery<T> objekat ciji interfejs IQueryable<T> ti dobijes kao rezultat ekstenzije. Dakle, zaustavi se nakon sto kreiras aerodrom IQueryable i ispitaj aerodromi i videces da je tipa:
System.Linq.IQueryable<SampleL2SvsEF.EF.Aerodrom>
{System.Data.Objects.ObjectQuery<SampleL2SvsEF.EF.Aerodrom>}
Samim tim castovanje nije kroz custom operator (koji bi mogao da napravi penale) vec direktno i u asembleru se svodi svodi se na dodelu/kopiranje reference:
Code:
// var aerodrom2 = (ObjectQuery<EF.Aerodrom>)aerodromiqueryable;
000002f4 lea rcx,[000B13E0h]
000002fb mov rdx,qword ptr [rsp+38h]
00000300 call FFFFFFFFF33EE400
00000305 mov qword ptr [rsp+40h],rax
REG: RAX (posle call) = 00000000028250A8 RDX (pre call) = 00000000028250A8
Tako da slobodno mozes da castujes EF query-e u ObjectQuery da bi dobio njegove metode bez performance penala. To je jedna od lepih osobina i osnova univerzalnosti LINQa
Takodje, LINQ query i ekstenzije su jedno te isto. Tj sledeca tri koda generisu isti IL
Code (csharp):var ef
= new EF
.nasabazaEntities();
var x1
= from a
in ef
.Aerodroms.Where(c
=> c
.AerodromID == id
) select a
;
var x2
= from a
in ef
.Aerodroms where a
.AerodromID == id
select a
;
var x3
= ef
.Aerodroms.Where(c
=> c
.AerodromID == id
);
kad disasm ovaj kod dobijes sledece jer je IL identican
Code (csharp):nasabazaEntities ef
= new nasabazaEntities
();
IQueryable
<Aerodrom
> x1
= from a
in ef
.Aerodroms where a
.AerodromID == 1 select a
;
IQueryable
<Aerodrom
> x2
= from a
in ef
.Aerodroms where a
.AerodromID == 1 select a
;
IQueryable
<Aerodrom
> x3
= from c
in ef
.Aerodroms where c
.AerodromID == 1 select c
;
Tako da u sve svrhe i primene Do__Linq2EntityTest i Do__EntitySQLObjectQueryTest su jedno te isto i zato i dobijas priblizno iste rezultate. Jedini razlog zbog kojeg sam ga castovao je upravo da bi izvukao SQL skriptu.
---------------------------------------------------------------------------
E sad, sto se tice EntityCommand-a
To je varanje, Entity command je untyped mehanizam koji uzima svoju funkcionalnost iz System.Data.Common.DbCommand. Dakle jedino sto EF tu ucestvuje je da svojim provajderom generise DB (SQL) skriptu iz modela i da pruzi informaciju o konkretnoj DB konekciji. Ono sto dobijes na kraju u EntityResult je imlpementacija Common.DBDataReadera-a koji ti vraca flat untyped recordset Common.DbDataRecord objekata. Samim tim pati od istih falinki od kojih pati i klasicni SlqlDataReader pristup.
Dakle, nadam se da je sad ociglednije zasto je brzi. Brzi je zato sto nema drugi deo jednacine, rezultati ne idu nazad u EF da se mapiraju u typed objekte i da se nad njima izvrsi integrity provera. Zato ga ne mozemo porediti sa L2S i "punim" EF pristupom jer nisu u istoj kategoriji (typed vs untyped). Ako ga mozemo porediti sa necim onda je to sa klasicnim data readerom od kojeg je opet 50% sporiji.
Prema tome u kateogriji "MSSQL, typed, no ORM", sto je priblizno i najcesca primena, L2S i dalje sije konkurenciju.
[Ovu poruku je menjao mmix dana 28.09.2010. u 12:03 GMT+1]
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ć
ADO.NET Entity Framework vs Linq2SQL
