Järelkaja Entity Framework 4.0 seminarile
13.03.2010 | GunnarKolmapäeval lobisesin inimestele Entity Framework 4.0 teemadel. Ettekande käigus sai tehtud üks pisikene avastus ja et ma sündmusele eelneva kandeni tänu ajanappusele ei jõudnud, siis jagan käesolevas kandes lisaks pisiavastusele ka mõned asjakohased viited, mis huvi võiks pakkuda.
Esiteks kõigile osalejatele ja e-osalejatele suured tänud, et kuulama tulite ja veel suuremad tänud põnevate küsimuste ja märkuste eest! Ega teisiti vinged tehnoloogiaüritused sündida saagi. 
Aga asja juurde.
Mõni päring on optimaalne
Pisike avastus, mis tehtud sai, oli see, et EF4.0 suudab anonüümsete tüüpide põhjal teha optimaalsed päringud. Ehk siis – päringus küsitakse ainult nii palju välju kui on vaja. Ettekandes näitasin sellist mudelit.
Järgmiseks käivitame sellise päringu ja vaatame, millise SQL-i see koostab.
select new { Id = e.Id, Title = e.Title };
Debug.WriteLine(((ObjectQuery)query).ToTraceString());
Tulemus on üle ootuste hea.
SELECT
[Extent1].[event_id] AS [event_id],
[Extent1].[title] AS [title]
FROM [dbo].[events] AS [Extent1]
Mõni päring ei ole optimaalne
Omalt poolt seadsin kahtluse alla T-SQL päringute optimaalsuse, mis olla võrreldes varasemaga paranenud. Aluseks võtsin Ayende Rahien blogi postituse What happens behind the scenes: NHibernate, Linq to SQL, Entity Framework scenario analysis, kus tuuakse võrdlus NHibernate, LINQ To SQL ja LINQ To Entities vahel. Entity Framework, mis kasutab LINQ To Entities tehnoloogiat, on suhteliselt lihtsates olukordades suuteline näiteks sellisteks päringuteks.
Et tegemist oleks efektiivse päringuga, on enam kui kaheldav. Ma loodan siiralt, et enne kosmonautikapäeva, mil on oodata Visual Studio 2010 esimest valmis versiooni, muutub ka EF4.0 SQL-i koostamise strateegia efektiivsemaks. Kindlasti saab ise natukene mõjutada väljundiks olevat SQL-i, kuid by default selliseid üllatusi valmis tootes küll näha ei sooviks.
LINQ To Entities päringute monitoorimine
Selleks, et päringuid paremini monitoorida, saab kasutada näiteks ObjectQuery objekti, nagu näidatud eespool. Sel juhul tuleb ise meeles pidada, et kõik monitooritavad päringud kuskilt loggerist läbi tuleb lasta. Mugavam variant on kasutada spetsiaalset töövahendit, millel nimeks Entity Framework Profiler.
Tegemist on tasulise vahendiga, mille abil saab väga hea ülevaate sellest, mida EF teeb, samuti on Entiry Framework Profiler võimeline analüüsima SQL-i ja andma hoiatusi päringute kohta, mis võivad jõudlusele ohtlikud olla. Entity Framework Profiler töötab ka Entity Framework praeguse versiooniga, samuti saab seda kasutada integratsiooniserverites.
Lõpetuseks
Ayende blogis toodud päring jäi mul ajapuudusel ettekandest välja, samuti Entity Framework Profiler. Esimene neist teemadest on selge signaal selleks, et mapperi loodud päringuid tuleb alati kontrollida. Teine teema on aga elegantne lahendus esimesele. Sarnased profileerimise vahendid on olemas ka NHibernate ja LINQ To SQL jaoks.