Dapper.NET

Amikor adatbázisokkal dolgozunk az egyik legalapvetőbb “művelet”, hogy a táblánk soraiból objektumokat gyártunk. Az évek során rengeteg megközelítés született, többek között az ORM rendszerek. .NET oldalon itt van nekünk az Entity Framework illetve régebben a Linq To SQL és persze ne feledkezzünk meg az NHibernate-ről sem. Azonban ezek az eszközök meglehetősen nagy tudást, tapasztalatot igényelnek és bizony gyakran belefutunk furcsa viselkedésbe.

Van azonban az ORM eszközöknek egy vadhajtása, ún. Micro-ORM-ek, minimalista, gyakran mindössze 2-3 ezer soros könyvtárak. .NET Framework esetében ezek a könyvtárak kihagyják a LINQ-t és közvetlenül az ADO.NET-re épülnek, a tábla-objektum átvitelt pedig reflection segítségével oldják meg.

Több ilyen Micro-ORM is létezik, talán a leghíresebb a Dapper, amely a stackoverflow.com egyik építőköve:

https://code.google.com/p/dapper-dot-net/

A Dapper egyetlen 3355 soros forrásfájlból áll és az IDbConnection interfészre telepszik rá extension method-ok formájában. Legegyszerűbb, ha NuGet csomagból telepítjük, ehhez a szokásos jobb klikk a projekten, majd Manage NuGet Packages és keressünk rá a Dapper-re:

1

Fájdalommentes telepítés után használatba is vehetjük. A példákban a már megszokott blog adatbázist használjuk majd. Néhány szót a teljesítményről: általában azt szoktuk meg, hogy az ORM rendszerek nem a sebességbajnokai. Az Entity Framework 4-es sorozata sokszor szánalmasan lassú volt, ez az 5-ös verziót már szerencsére nem érinti. Ettől függetlenül a nyers erő nem elég, gondolkodni is kell és főleg ismerni a rendszer működését. A Dapper-hez hasonló micro keretrendszerek kifejezetten gyorsak és legfőképpen nem kell sokat szerencsétlenkedni velük, különösebb trükközés nélkül hozzák a teljesítményt.

Maga a Dapper nagyon közel jár a nyers ADO.NET-hez. Azt még megjegyzem, hogy a hivatalos oldalon lévő tesztek némileg elavultak, ott az Entity Framework 4.1 szerepelt még és bizony rendesen el is verték rajta a port. A Dapper vs. “sima” ADO.NET eredmények viszont még mindig helyt állnak.

No, elég a fecsegésből, csináljunk is valamit! Kezdjük a kiválasztással, a Query extension method ezen változata egy paramétert fogad, ez pedig a futtatni kívánt SQL:

using (SqlConnection connection = new SqlConnection(Program.ConnectionString))
{
    connection.Open();

    var result = connection.Query<User>("select * from Users");

    // ...

Csak viszonyításképpen, az állandóan felhozott ősöreg processzorom 3 másodpercen belül átrohant a 300000 soron és elkészítette az objektumaimat. Az eredményt IEnumerable formában kapjuk vissza.

Ez eddig egyszerű, mi van akkor ha fel is akarom paraméterezni a lekérdezésemet? Újabb Query változatot veszünk elő:

var result = connection.Query<User>(
    "select * from Users where Username=@UserName",
    new { Username = "IstvanReiter" });

Mindössze egy anonim típust kell készítenem, amelyen belül felsorolom a szükséges értékeket. Ha több táblából akarom összeszedni az értékeket akkor sincs baj, mivel a Query generikus paraméter nélküli változata pont erre való. Ekkor IEnumerable<dynamic> lesz a végeredmény:

var resultDynamic = connection.Query(
        "select Users.Username, Posts.Title from Users, Posts"
    );

Azokat a parancsokat, amelyek nem adnak vissza eredményt az Execute függénnyel tudjuk meghívni. A Query-hez hasonlóan ez is felparaméterezhető egy anonim típussal:

connection.Execute(
    "update Users set Password = @Password where Id = @Id",
    new { Password = "almafa", Id = 1 });

Látható tehát, hogy egyszerű ám nagyszerű eszközzel van dolgunk.

Reklámok
Tagged with: ,
Nincs kategorizálva kategória
8 comments on “Dapper.NET
  1. Attila Goda szerint:

    A gond csak az ezzel, hogy az SQL-ed string formában adod át, amitől kb. annyira lesz megbízhatatlan a rendszered, mint ha PHP-ben vagy javascriptben követted volna el.

    • reiteristvan szerint:

      Nézd, az Entity Framework előtt is volt élet, megoldottuk akkor is valahogy. Nem beszélve arról, hogy semmi perc alatt össze lehet dobni pár függvényt ami legenerálja az SQL-t paraméterek alapján.

      Ami a PHP-t és Javascript-et illeti, bár egyik sem a kedvencem, de nem szükségszerűen instabil az amit csinálnak velük. Nyilván nagyobb eséllyel találsz szar kódot, mert boldog boldogtalan ezeket használja.

    • hurka szerint:

      Az entity framework is “string formában” adja át az sql-t….

    • Pal Vojacsek szerint:

      Véleményem szerint a megbízható alkalmazás nem attól lesz megbízható, hogy milyen nyelvben fejlesztik, inkább attól, hogy kik, és hogyan. Úgy tudom van pár C++-ban és PHP-ban megírt megbízható alkalmazás, és láttam ennek ellentétét már .net-ben és java-ban párszor. Itt inkább az ellenőrizhetőség, és a change management lehet kérdéses (de ezek automatizált tesztekkel jól kezelhető dolgok).

      • reiteristvan szerint:

        Így van, egy programozási nyelv vagy környezet csak eszköz, az emberen múlik mit kezd vele.

      • gsek szerint:

        Ez tény, de mondjuk ha fordítási hibát kapunk a hibás adatmodell lekérdezésünkre, az gyorsíthat a fejlesztési folyamatokon (nem kell minden alkalommal unit testeket futtatni). Ráadásul lekérdezéseket elég probélmás automatikusan tesztelni, gondolok itt inkább az írás műveletekre. Nyilván ezeket meg lehet oldani minden környezetben, de típusos lekérdezésekkel nem tudod kikerülni

    • eMeL szerint:

      Ez nem minden alkalommal hátrány.
      Nem véletlen, hogy a LinQ-hoz is létrejött a LinQPad.
      Egyszerűen nem igaz, hogy minden alkalommal a kód írása közben kell megalkotni a lekérdezést. Sőt!
      Bonyolult lekérdezéseknél nagyon fontos, hogy egy külső eszközzel teszt adatokon lekérdezést csináljunk, elemezzük az eredményt (ami gyakran nem egyszerűen egy rátekintés, hanem az eredmény elemeinek újabb lekérdezésekkel ellenőrzése).
      Erre pedig manapság is az SQL az egyik legjobb eszköz.
      Ad hock vagy nagyon összetett lekérdezésekre nem tudok jobbat.
      Ne feledd, hogy ha az adattároló eszközöd az SQL-t preferálja, akkor nagyon összetett lekérdezésekhez csak az SQL adhat valóban hatékony megoldást.
      Nem beszélve arról, hogy nem ritkaság, hogy több eszközzel is *ugyanazt* a lekérdezést akarod látni. Pl. a programod mellett pl. egy report eszközzel…

      Szóval én nem temetném annyira az SQL-t. Ha nem kezd el valaki vadul szövegmanipulálással SQL-eket gyártani, hanem főként konstans textekből[*] dolgozik, akkor megvan annak a létjogosultsága.

      [*]: persze lehet szövegmanipulálni is, és ha ezt egy jól megcsinált könyvtár csinálja, akkor nincs is gond. Mondok példának két jól tesztelt könyvtárat: DLinQ és EF 😉

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés /  Módosítás )

Google kép

Hozzászólhat a Google felhasználói fiók használatával. Kilépés /  Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés /  Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés /  Módosítás )

Kapcsolódás: %s

Írtam
%d blogger ezt kedveli: