Sergejus apie .NET

Vienas dažniausiai man užduodamų klausimų, susijusių su ORM įrankiais - integracija su išsaugotomis procedūromis (Stored Procedure). Šiandien aš norėčiau parodyti kaip tai daroma su Entity Framework 4.

Pirma apibrėžkime išsaugotą procedūrą (priminsiu, aš dirbu su Blog modeliu):

Kaip matote, mes grąžiname straipsnių skaičių, priskirtų konkrečiai kategorijai, kartu su kategorijos ID ir pavadinimu.

Tolesniam darbui, mums bus reikalingas kompleksinis tipas, skirtas grąžinamai struktūrai apdoroti:

Dabar beliko atnaujinti mūsų modelį …

 … įtraukiant naujai sukurtą išsaugotą procedūrą:

Tam, kad iškviesti šią išsaugotą procedūrą kaip metodą, būtina padaryti „funkcijos importą” …

… ir pasirinkti prieš tai sukurtą kompleksinį tipą kaip grąžinimą tipą:

Štai ir viskas, dabar mes turime tipizuotą išsaugotos procedūros analogą:

Kadangi GetPostCountByTag grąžina C# objektą, darbas su išsaugotomis procedūromis bei funkcijomis pasidaro kaip niekada intuityvus:

Štai ir viskas šiam kartui. Tikiuosi man pavyko parodyti, kad Entity Framework ir išsaugotos procedūros yra visai suderinami dalykai.

Atėjo laikas aprašyta vieną svarbiausių Entity Framework 4 naujovių - pagerintą darbą kelių sluoksnių aplikacijose. Savo pavyzdyje aš papildomai naudosiu Entity Framework Feature CTP1.

Priminsiu, kad mes dirbame su tokiu modeliu:

Pradėsime nuo to, kad vietoje standartinių EF esybių, mes sugeneruosime taip vadinamas „save stebinčias” (self-tracking) esybes iš EF Feature CTP1:

Generuojamos esybės visiškai nepriklauso nuo Entity Framework, kas leidžia nenaudoti nuorodos į Microsoft.Data.Entity.dll. Šalia duomenų konteksto ir pačių esybių, generuojamos kelios pagalbinės klasės, tame tarpe EntityChangeTrackerAdapter ir ObjectChangeTracker - kurie saugo visus objekto pakeitimus.

Apibrėžkime klasę PostService, kuri turės du metodus darbui su straipsniais: GetPostById ir Save:

Metode GetPostById aš išreikštinai įjungiu automatinį pakeitimų sekimą, nes be jo neveiks kitas mūsų metodas Save. Taip pat šiame metode užklausoje aš nurodau, kad kraunant straipsnius, reikia pakrauti ir susijusius komentarus.

Metode Save aš iškviečiu praplėtimo metodą ApplyChanges, kuris apeina visą esybės grafą ir atlieka reikalingus pakeitimus. Norint pasinaudoti šiuo praplėtimo metodu, būtinai reikia į using dalį įtraukti vardų sritį Microsoft.Data.Objects. ApplyChanges antru parametru priima delegatą, kuris grąžina IEntityChangeTracker interfeisą realizuojantį objektą (automatiškai generuojamas).

Turint servisų klasę, galima pereiti ir prie konkretaus panaudojimo pavyzdžio:

Kaip matyti, pirma aš gaunu atjungtą nuo duomenų konteksto esybę post, sukuriu naują komentarą ir jį pridedu į pradinį straipsnį, po ko išsaugau pakeitimus. Toliau aš dar kartą kreipiuosi į duomenų bazę, pakraunu esybę su prieš tai sukurtu komentaru ir pažymiu jį trynimui. Noriu atkreipti dėmesį, kad visos save stebinčios esybės turi metodus MarkAsUnchanged, MarkAsModified, MarkAsDeleted, MarkAsAdded.

Taigi taip paprastai ir patogiai mes galėjome operuoti esybių grafais atjungtoje (disconnected) aplinkoje. Pagaliau ateina laikas, kada WCF ir ASP.NET aplikacijose bus paprasta operuoti esybių grafais!

Praeitoje dalyje aš aprašiau Entity Framework 4 POCO palaikymą. Jums galėjo kilti natūralus klausimas: kam reikia aprašinėti POCO rankomis, jeigu jau turime aprašytą koncepcinį modelį (CSDL failą). Nors EF4 Beta 1 palaiko tik vieną (ne POCO) T4 generavimo šabloną, prieš porą savaičių pasirodžiusi pirmoji Entity Framework 4.0 Feature CTP versija pateikia ir taip laukiamą T4 POCO šabloną. Trumpai aprašysiu kaip galima pasinaudoti šiuo šablonu ir automatiškai sugeneruoti reikalingas POCO klases.

Pirma reikia įsitikinti, kad EDMX failo Custom Tool savybė yra išvalyta:

Tada dizaineryje iš kontekstinio meniu pasirenkame punktą Add New Artifact Generation Item (ateinančiose EF versijose jis vadinsis kitaip):

Atsiradusiame Add New Item lange nurodome EntityFramework POCO Code Generator:

 Rezultate mums bus sugeneruotas duomenų kontekstas ir visos POCO klasės:

Sugeneruotos klasės atrodo pakankamai švariai, bet neaiškumų man kilo dėl kompleksinių savybių kodo:

Noriu priminti, kad šis T4 POCO generavimo šablonas yra pakankamai ankstyvoje stadijoje ir esu įsitikinęs, kad jis dar keisis nekartą. Nepaisant to, manau sutiksite, tai yra didžiulis Entity Framework žingsnis pirmyn, lyginant su pirma versija!

Antroje Entity Framework 4 dalyje aš aprašiau naują „pirmą modelis” galimybę. Tada mes apsistojome ties tokiu koncepciniu modeliu:

Šiandien aš norėčiau jums parodyti, kaip galima naudoti POCO (Plain Old CLR Object) kartu su Entity Framework 4. Tam reikia atlikti keletą paprastų žingsnių:

1. Kada norima patiems aprašyti modelio klases, pirma reikia uždrausti Entity Framework generuoti jo standartinius objektus. Tai galima padaryti ištrynus Custom Tool savybės reikšmę:
   
2. Dabar mes turime EDMX failą be jokių sugeneruotų C# klasių. Remiantis mūsų modeliu, aprašome atitinkamas POCO klases:
   
3. Turint modelio klases, laikas aprašyti duomenų kontekstą. Naujojo IObjectSet interfeiso pagalba, duomenų kontekstas dabar gali būtų labai paprastai testuojamas:
   

Štai mes ir galime pradėti dirbti su Entity Framework. Pradžiai, sukurkime straipsnį ir vieną gairę (tag):

Kodas yra pakankamai akivaizdus, išskyrus metodą FixUpTag. Pateiktame pavyzdyje, aš priskiriu gairę „Entity Framework” naujam straipsniui. Tai reiškia, kad esybė tag turėtų irgi rodyti į naujai apibrėžtą straipsnį. Tai vadinama sąryšio sutvarkymu. Deja, pirmoji Entity Framework 4 Beta versija automatiškai to nepadaro, bet anot EF komandos, tai bus sutvarkyta ateinančioje Beta versijoje, todėl mano metodas FixUpTag yra tik laikinas sprendimas.

Įvykdžius aukščiau pateiktą kodą, natūraliai duomenų bazėje atsiranda visi reikalingi įrašai:

Dar vienas svarbus niuansas - objekto pakeitimų stebėjimas. Įvykdžius žemiau pateiktą kodą mūsų aprašytiems POCO, gausime nevisai to ko tikimės:

Tam, kad gauti visus objekto pakeitimus galima rankiniu būdu iškviesti metodą context.DetectChanges() arba, kas rekomenduojama iš greitaveikos pusės, pažymėti visas objekto savybes kaip virtual:

Entity Framework moka nurodytiems POCO generuoti proxy klases, ir virtualių savybių pagalba gali perrašyti jas taip, kad visi pasikeitimai būtų automatiškai stebimi:

Taip pat noriu pabrėžti, kad nuorodos į kitus objektus (ICollection<Tag>, Post ir pan.), turėtų visada būti virtualios savybės, nes tik šiuo atvejų Entity Framework palaikys duomenų pakrovimą pagal poreikį (lazy-loading).

Tiek šiam kartui iš POCO, kitą kartą parodysiu kaip galima automatiškai generuoti POCO pasinaudojant T4 šablonais iš Entity Framework 4.0 Feature CTP 1.

Štai ir atėjo laikas antram straipsniui iš Entity Framework 4 serijos. Šiandien aš trumpai aptarsiu kelias naujoves: „pirma modelis” ir „kompleksinės savybės”. Šiame straipsnyje aš detaliai nenagrinėsiu esybių pridėjimo ir panašių dalykų, kas nuo pirmos versijos praktiškai nepasikeitė, o susikoncentruosiu išskirtinai ties naujovių.

Pradėsime nuo tuščio duomenų modelio pridėjimo. Nors pirmoje versijoje ši galimybė jau egzistavo, praktikoje ji neveikė. Ketvirtoje Entity Framework versijoje tai yra ištaisyta.

Sukūrę tuščią duomenų modelį pasižiūrėkime ką siūlo kontekstinis meniu:

Lyginant su pirma versija, atsirado tokios galimybės kaip duomenų bazės skripto generavimas, generavimo artifakto pridėjimas, kompleksinės savybės ir daugiau.

Kas man nelabai patiko, kad šiuo metu visos eilutės pagal nutylėjimą nepalaiko Unicode, tai reikia įjungti išreikštinai:

Aš ką tik iškėliau šį klausimą EF komandai ir gavau atsakymą, kad tai yra klaida, kuri šiuo menu yra taisoma. Pagal nutylėjimą eilutės BUS Unicode.

Kaip aš jau rašiau, naujoje Entity Framework versijoje atsirado galimybė kurti ir redaguoti kompleksines savybes tiesiogiai iš interfeiso (anksčiau tam reikėjo redaguoti susiejimo failus):

Kaip matyti, aš sukūriau kompleksinę savybė Author, kurią sudaro trys laukai: Blog, Email ir Name. Aiškumo dėlei pažymėsiu, kad kompleksinės savybės duomenų bazėje saugomos kartu su esybių savybėmis, o logiškas atskyrimas yra tik koncepciniame lygmenyje:

Šiame straipsnyje aš kursiu blogo modelį, sudarytą iš trijų pagrindinių esybių: komentarai, gairės (taip, taip, Tag oficialiai verčiamas kaip gairė) ir straipsniai. Tarp straipsnių ir gairių apibrėžtas daug su daug ryšis, o tarp straipsnių ir komentarų - vienas su daug. Norėdami pagal tokį koncepcinį modelį sugeneruoti duomenų bazės schemą, užtenka iškviesti kontekstinį meniu ir jame pasirinkti atitinkamą punktą:

Šiuo metu duomenų bazės schemos generavimas yra sudarytas iš dviejų etapų: SQL sakinių generavimo ir jų vykdymo reikalingoje duomenų bazėje. Ateityje antras etapas tikriausiai bus automatizuotas.

Pasirinkus Generate Database Script from Model, atsiranda vedlys, kuriame reikia nurodyti prisijungimo eilutę ir (jeigu reikia) sukurti tuščią duomenų bazę:

Rezultate mes turime pagal modelį sugeneruotus SQL sakinius, kurie iš karto bus išsaugoti atskirame faile:

Sugeneruotus ir išsaugotus SQL sakinius mes galime įvykdyti reikalingoje duomenų bazėje:

Atkreipkite dėmesį į tai, kad kompleksinės savybės elementai turi prefiksą Author, o mūsų daug su daug ryšiui tarp straipsnių ir gairių bus automatiškai sukurta tarpinė lentelė PostTag. Įvykdžius šiuos SQL sakinius, duomenų bazės schema atrodys taip:

Štai ir viskas! Toks duomenų bazės schemos kūrimo būdas tikriausiai bus kritikuojamas DB administratorių, bet mums, programuotojams, jis yra žymiai intuityvesnis.

Kitame straipsnyje aš pademonstruosiu Entity Framework 4 POCO palaikymą.

Savo trumpoje Entity Frarmework 4.0 apžvalgoje aš paminėjau, kad nors pirmoje beta versijoje ir nėra šablonų, skirtų generuoti POCO arba pakeitimus sekančius (self-tracking) objektus, tokia galimybė turi atsirasti. Šiandien viešai pasirodė pirmoji CTP versija Entity Framework 4.0 Feature, kurioje aukščiau išvardintus dalykus jus ir galėsite rasti.

Viena svarbiausių (bent jau man) Visual Studio 2010 naujovių - Entity Framework 4. Nors tikroji Entity Framework versija ir yra 2, suvienodinimui oficialiai jis vadinasi pagal .NET Framework versiją, t.y. EF 4. Verta pabrėžti, kad nors EF 1 ir buvo pozicionuojamas kaip galingesnis ORM įrankis negu LINQ to SQL, dėl savo neužbaigtumo ir elementariausių funkcijų nebuvimo, LINQ to SQL buvo naudojamas žymiai dažniau. Pirmoji versija sulaukė tikrai nemažos kritikos ir dėl to ypač džiugu, kad Microsoft rimtai pasižiūrėjo į nauja EF versiją. Šiame straipsnyje aš trumpai aprašysiu visus pasikeitimus nuo pirmos versijos, o kituose straipsniuose - išnagrinėsiu pagrindines naujoves detaliau.

Atvirai tariant, jeigu EF 1 savo projektuose aš nenorėjau naudoti (naudojau LINQ to SQL), tai 3 savaites padirbęs su EF 4 galiu teigti, kad kitas mano projektas tikriausiai naudos naują Entity Framework. Kas gi atsirado naujo?

POCO

Pagaliau! Paskutiniu metu aš esu didelis POCO (Plain Old CLR Object) proponentas, nes jų pagalba galima aprašyti saugojimui neutralias klases, kurios realiai nepriklauso nei nuo konkretaus duomenų šaltinio, nei nuo kitų sąlygų. EF 4 leidžia aprašyti EDMX modelį ir kartu su juo naudoti POCO klases.

Testuojamumas

Iki šiol, tam kad prieiti prie duomenų bazės lentelių, Entity Framework duomenų kontekste naudojo ObjectQuery<T> klasę. Dabar atsirado klasė ObjectSet<T>, kuri paveldi iš ObjectQuery<T> ir realizuoja interfeisą IObjectSet<T>. Tai reiškia, kad pagaliau testavimo metu mes galime pakeisti duomenų konteksto realizaciją.

Pirma modelis

EF 1 reikalavo egzistuojančios duomenų bazės schemos. EF 4 gi leidžia pirma sukurti verslo esybes ir sąryšius tarp jų, o tik paskui pagal tai sugeneruoti duomenų bazės schemą.

Kodo generavimas

Tiek LINQ to SQL, tiek EF 1 turėjo nemažą trūkumą - mes neturėjome būdo įtakoti generuojamo kodo. EF 4 kodo generavimui naudoja T4 (Text Template Transformation Toolkit). Kartu su Visual Studio 2010 Beta 1 yra pateikiamas vienintelis kodo generavimo šablonas, kuris naudoja ObjectSet bazines klases, bet MVP Summit metu buvo pažadėta, kad Microsoft komanda papildomai išleis POCO generavimo šabloną bei šabloną skirtą N-sluoksnių aplikacijų kūrimui.

LINQ operacijos

Kaip nebūtų keista, bet skirtingai nei LINQ to SQL, EF 1 turėjo prastą LINQ operacijų palaikymą. Taip, pavyzdžiui, nebuvo palaikomos tokios operacijos kaip Contains, DefaultIfEmpty, First, FirstOrDefault. Nuo dabar palaikomos praktiškai visos LINQ operacijos, kas leidžia testavimui naudoti ne LINQ to Entities, bet LINQ to Objects.

Lazy Loading

Sunku suvokti, bet pirmoji Entity Framework versija nepalaikė automatinio duomenų pakrovimo pagal poreikį (Lazy Loading). Laimei, tai yra sutvarkyta EF 4.

N-sluoksnių aplikacijos

Valio! Attach, Detach, automatinis esybių būsenos stebėjimas ir kiti pakeitimai. Daugiau informacijos apie tai viename iš būsimų straipsnių.

Vardų servisas

Ką LINQ to SQL mokėjo nuo pat pradžių, Entity Framework tik dabar objektų vardus paverčia į vienaskaitą, o 1:N ir N:M ryšių pavadinimus - į daugiskaitą.

Kompleksinės savybės

Ženkliai supaprastėjo darbas su EF kompleksinėmis savybėmis, kurias dabar galima kurti tiesiai iš Entity Framework grafinio redaktoriaus.

Varotojo apibrėžtos funkcijos

Taip! Pagaliau vartotojo apibrėžtos funkcijos (UDF) prieinamos tiesiai iš Entity SQL.

Šiame straipsnyje aš trumpai aprašiau visas pagrindines Entity Framework naujoves. Kitoje dalyje aš jau pereisiu prie konkrečių pavyzdžių.

Taigi kaip ir žadėjau, šiandien parodysiu kaip galima įgalinti naudoti Entity Framework kartu su POCO. Prieš tęsiant labai rekomenduoju dar karta peržiūrėti mano ankstesnius straipsnius skirtus Entity Framework.

Pirma reikia parsisiųsti Entity Framework POCO adapterio projektą. Toliau naudosime du failus: EFPocoAdapter.dll ir EFPocoClassGen.exe. Savo pavyzdyje paprastumo dėlei aš praleisiu verslo logikos arba servisų sluoksnį bei naudosiu gerai žinomą Northwind duomenų bazę. Aš jau rodžiau kaip galima pridėti Entity Framework EDMX failą nurodytai duomenų bazei, todėl iškarto pereisiu prie pradinės mano Visual Studio sprendimo struktūros:

Pasirinkus, kad Entity Framework sugeneruotų esybes ir susiejimus tik lentelėms, turėtumėte matyti panašų vaizdą:

Kadangi POCO panaudojimas kartu su Entity Framework remiasi tam tikru papildomu kodo generavimu, pridėkime EFPocoAdapter.dll ir EFPocoClassGen.exe į mūsų Data projektą:

Paprasčiausias būdas sugeneruoti POCO pagal mūsų EDMX failą, pasinaudoti EFPocoClassGen įrankiu. Tam galima sukonfigūruoti jį kaip išorinį Visual Studio įrankį. Tam nueiname į Tools → External Tools ir pridedame naują įrankį:

Komandos laukelyje įvedame $(SolutionDir)Data\Dependencies\EFPocoClassGen.exe, o argumentų laukelyje - /mode:PocoClasses /inedmx:$(SolutionDir)Data.Model\Northwind.edmx /outputDir:$(SolutionDir) /map:Data.Model=Data.Entities.

Trumpai paaiškinsiu perduodamus argumentus. Mode argumentas nusako kas bus generuojama: POCO klasės, POCO adapteris ar POCO konteineris (kontekstas). Inedmx argumentui perduodame kelią iki mūsų EDMX failo. OutputDir argumentas nurodo kur turi būti patalpintos sugeneruotos POCO klasės (visos klasės bus automatiškai talpinamos kataloge, kurio vardas sutaps su klasių  vardų sritimi). Map argumentas leidžia sugeneruotas klases patalpinti į tam tikrą naują vardų sritį. Tai reikia tam, nes Entity Framework jau turi sugeneruotas esybes su tokiais pačiais vardais, todėl POCO esybės turi priklausyti kitai vardų sričiai.

Išsaugojus nustatymus ir iškvietus šį įrankį iš meniu Tools, bus sugeneruotos POCO klasės, kurias mes turime įtraukti į Data.Entities projektą

Sugeneruotos POCO klasės pavyzdys pateiktas žemiau:

Kas svarbu, POCO klasės nenaudoja jokių Entity Framework specifinių klasių kaip EntitySet ar EntityRef. Nepaisant to, POCO adapteris leidžia pasinaudoti duomenų pakrovimu pagal poreikį galimybe (Lazy Loading). Tam tereikia reikiamas savybes pažymėti kaip virtual arba jų tipą pakeisti į interfeisą (kaip yra su kolekcijomis)

Šiam momentui mes turime Entity Framework POCO klases, bet tam kad jas panaudoti reikia dar sugeneruoti patį POCO adapterį bei POCO konteinerį (kontekstą). Rekomenduojama šį generavimą automatizuoti susiejant su projekto pre-build įvykiu. Tam einame į projekto savybes, pasirenkame kortelę Build Events ir į Pre-build laukelį įvedame dvi komandas:

“$(ProjectDir)Dependencies\EFPocoClassGen.exe” /mode:PocoAdapter “/inedmx:$(SolutionDir)Data.Model\Northwind.edmx” “/outputfile:$(ProjectDir)NorthwindAdapter.cs” “/ref:$(SolutionDir)\Data.Entities\bin\$(ConfigurationName)\Data.Entities.dll” /map:Data.Model=Data.Entities

“$(ProjectDir)Dependencies\EFPocoClassGen.exe” /mode:PocoContainer “/inedmx:$(SolutionDir)Data.Model\Northwind.edmx” “/outputfile:$(ProjectDir)NorthwindEntities.cs” “/ref:$(SolutionDir)\Data.Entities\bin\$(ConfigurationName)\Data.Entities.dll” /map:Data.Model=Data.Entities

Kaip ir anksčiau, mes pasinaudojame EFPocoClassGen įrankio pagalba. Rezultate gauname dvi klases NorthwindAdapter ir NorthwindEntities. Kadangi sugeneruotos klasės naudoja POCO esybes ir Entity Framework, papildomai reikia pridėti nuorodas į Data.Entities.dll ir EFPocoAdapter.dll

Turint POCO klases, POCO adapterį ir POCO konteinerį, mes galime pagaliau pereiti prie jų panaudojimo. Kaip ir dera, pirma mes turime apsirašyti Entity Framework prisijungimą prie duomenų bazės bei nurodyti kelią iki schemos aprašo, sąsajos aprašo ir esybių aprašo. Minėti trys failai automatiškai įeina į EDMX failą ir yra įkompiliuojami kaip resursai, todėl prisijungimo eilutė mano atveju atrodys taip:

Pats POCO klasių panaudojimas praktiškai niekuo nesiskiria nuo Entity Framework klasių naudojimo

Taigi tiek Entity Framework naujienų šiam kartui, lauksime pilno POCO palaikymo antroje Entity Framework versijoje.

Šiandien iš vieno pažįstamo išgirdau klausimą ar Entity Framework jau yra išleistas? Atsakymas – taip. Kartu su Visual Studio 2008 SP1 buvo išleista ir galutinė Entitity Framework versija. Šiuo metu jau prasidėjo darbas ties antra versija.

Vienas didžiausių naujos versijos patobulinimų bus DDD (Domain Driven Design) ir TDD (Test Driven Development) paradigmų palaikymas per POCO (Plain Old CLR Object). Pagrindinė mintis – esybės turi nieko nežinoti apie jų saugojimo būdą: duomenų bazę, XML failą ir pan. Kaip žinia, pirmoji Entity Framework versija (kaip ir LINQ to SQL) reikalauja, kad objektas būtų paveldėtas iš  tam tikros klasės ir/arba realizuotų tam tikrą interfeisą ir/arba turėtų tam tikrus atributus aprašančius meta duomenis.

Kuo man patinka besikeičianti Microsoft politika – tam tikrą kodą pateikti kuo anksčiau kaip beta versijas arba kaip atskirus mini-projektus. Taip atsitiko ir šį kartą. Jau kelias dienas aš bandau Entity Framework POCO adapterį.

Entity Framework sudaro keturios pagrindinės dalys: duomenų bazės schemos aprašas, esybių aprašai, sąsaja tarp DB schemos ir esybių bei sugeneruotas kodas. Naujasis projektas pateikia papildomą sluoksnį virš sugeneruotų Entity Framework klasių, adapterio pagalba leidžiant susieti POCO su Entity Framework objektais.

Pati mintis be jokių abejonių yra sveikintina, bet realizacija kol kas nėra ideali. POCO yra pririšti prie Entity Framework esybių aprašų kas automatiškai neleidžia naudoti DDD. Nepaisant to, prieinama realizacija padaro TDD kūrimą su Entity Framework įmanomu, todėl per ateinančias kelias dienas aš ir pateiksiu straipsnį iš POCO adapterio panaudojimo. Tiek šiam karui…

Praėjo porą savaičių nuo mano paskutinio straipsnio, skirto Entity Framework. Bandysiu pasitaisyti…

Dažniausiai objektinio-reliacinio susiejimo įrankių vengiama dėl to, kad jie generuoja dinamines CRUD (Create, Read, Update, Delete) užklausas. Entity Framework leidžia pasinaudoti savo privalumais net ir tokiais atvejais, kada CRUD turi būti realizuotas išsaugotų procedūrų pagalba. Pirmiausia prisiminkime, kaip atrodė mūsų esybės bei jų sąryšiai iš ankstesnių pavyzdžių:

Tarkime, esybei Users mes norime nurodyti, kad esybių kūrimui, atnaujinimui ir trynimui būtų naudojami ne dinamiškai generuojami SQL sakiniai, bet mūsų nurodytos išsaugotos procedūros. Šiam tikslui pirma apibrėžiame atitinkamas išsaugotas procedūras usp_INSERT_Users, usp_UPDATE_Users ir usp_DELETE_Users (išsaugotų procedūrų pavadinimai gali būti bet kokie). Toliau Mapping Details lange pereiname prie esybių ir funkcijų susiejimo skilties ir nurodome atitinkamas procedūras:

Pasirinkus konkrečią išsaugotą procedūrą, reikia susieti esybės laukus su procedūros parametrais:

Jeigu esybės laukų ir procedūros argumentų pavadinimai sutampa, Entity Framework juos susieja automatiškai, išorinių raktų (asociacijų) atveju reikia iš išsiskleidžiamo sąrašo pasirinkti susijusios esybės lauką.

Aprašant atnaujinimo procedūrą, galima jai nurodyti naudoti pradines reikšmes, t.y. lyginti ar atnaujinimo metu duomenų bazės lauko reikšmė sutampa su atnaujinamos esybės lauko reikšme:

Apibendrinant, galimybė nurodyti esybei CRUD išsaugotas procedūras bus tikrai naudinga projektuose, kur norima pasinaudoti Entity Framework galimybėmis, bet priimta naudoti ne dinaminius SQL sakinius, o išsaugotas procedūras. Tiek žinių šiam kartui ir sėkmės bebandant!