Czy Dapper to ORM?

Poprzedni wpis nt. biblioteki Dapper był tylko małą zachętą do sprawdzenia tej biblioteki, przetestowania jej i sposobu jej integracji w Twoim kodziku.

Tutaj poruszę temat trochę szerzej, z punktu widzenia kategorii ORMów. Kodziku nie będzie 😉

Nie o ORM

Celem wpisu nie jest omówienie „technologii” ORM. Celem jest omówienie zalet i wad stosowania tego podejścia, przy użyciu konkretnego reprezentanta jakim jest Dapper.

Namieszałem? Przejdę od razu do rzeczy, będzie jaśniej.

Cel Object-Relational Mapper

Należy się najpierw zastanowić nad celem stosowania ORMów. Czyli generalnie nad ich zaletami, bo to one sprawiają chęć ich używania.

Osobiście jestem zdania, że nie powinniśmy dzielić programisów na bazodanowych, back-endowch, front-endowych, aplikacyjnych itp. itd.

Nie zrozum mnie źle. Wiem, że ten podział wynika z ogromu technologii i wiedzy jaką trzeba ogarnąć i w jakiś sposób trzeba sobie wybrać niszę. Niekoniecznie aby się specjalizować, ale chociażby po to aby móc stworzyć coś w ramach jednej technologicznej domeny.

Moim zdaniem programista powinien potrafić ogarnąć kuwetę od początku do końca. Nie ekspercko. Kiedy potrzebny jest ekspert to się go wynajmuje.

Jednak co w przypadku kiedy potrzebujesz połączenia z bazą danych, potrzebujesz pracować na danych, bądź po prostu utrzymywać w jakimś stopniu bazę danych, ale nie znasz żadnej implementacji SQL czy innej formy zapytań do bazy?
Programujesz w paradygmacie obiektowym (chociaż to pewnie nie ma wielkiego znaczenia) i chcesz za sprawą swojej wiedzy i umiejętności być w stanie używać bazy danych w projekcie.

Właśnie w tym momencie z pomocą przychodzą ORMy.

Dapper w roli ORM

Jak w roli ORM sprawdza się biblioteka Dapper?

Zastanówmy się, co jako programiści możemy „dostajemy” dzięki użyciu ORM?

  1. Możliwość pisania do bazy danych, pobierania z bazy danych za pomocą znanego nam już języka programowania i znanego mi już modelu abstrakcji.
  2. Możliwość wymiany silnika bazodanowego, niezależnie od naszego kodu i bez jego modyfikacji. To ORM zajmuje się „tłumaczeniem”.
  3. Brak konieczności nauki np. SQLa (dla niektórych to zaleta, trudno oceniać).
  4. Szybkość wdrożenia projektu bazy danych w realne rozwiązanie, w realną bazę danych, również jest zaletą ORM.
  5. Optymalizacja zapytań do bazy danych, w większości przypadków stoi po stronie ORM. Nie trzeba się tym „martwić” na zapas. Podobno to zaleta, ale z doświadczenia wiem, że z tym różnie bywa ;-).
  6. Jako programistka/programista skupiamy się na logice biznesowej. Na tzw. „domenie”, a wszelkie w niej zmiany są od razu odwzorowane w modelu bazy danych.

Które z tych zalet pokrywają się z możliwościami jakie daje nam Dapper?

No to po kolei…

  1. Tak. Zdecydowanie można używać języka C# i budować integrację z bazą danych w sposób znany tylko programiście. W najbardziej prostym przykładzie sprawa ogranicza się do użycia metody extension i jako argument podania zapytania bądź komendy i ew. obiektu który chcemy np. „wepchać” do bazy. Tyle.
  2. Z tego co mi wiadomo, Dapper obsługuje wszelkiego rodzaju bazy danych implementujące któryś ze standardów SQL. Dzieje się to za sprawą tego, że Dapper implementuje interfejs IDbConnection, więc jeśli tylko jesteś w stanie przy jego pomocy podpiąć się pod bazę danych, Dapper da radę, ale jest jeden haczyk (o tym za chwilę).
  3. Brak konieczności nauki SQL? Stety/Niestety w tym przypadku tak NIE jest. Biblioteka Dapper została zbudowana właśnie m.in. wokół idei panowania nad tym jak wygląda zapytanie SQL. Zatem znajomość SQLa do użycia Dappera jest wymagana. Oczywiście mowa o „czystym” Dapperze.
  4. Dapper nie ma mechanizmów do migracji bazy danych, więc w ogóle nie rozważamy podejścia „code first” w tym przypadku. Można użyć Fluent Migrator, ale nie o tym rozmawiamy, prawda?
  5. Czy optymalizacja zapytań do bazy danych stoi po stronie ORM w przypadku użycia Dappera? No nie. Skoro sami piszemy zapytania w SQL to jedyną rolą Dappera jest zrobić tak, żeby wywołało się jak najszybciej. Co nie powinno być w ogóle zauważalne ponieważ Dapper to tylko pewien poziom wrappera na ADO.NET. Bardzo cienka warstwa która sprawia, że ADO.NET staje się bardziej „zjadliwe” i łatwiejsze w implementacji.
  6. Sądzę, że tak. Ten punk na konto Dappera. Wszak możesz wszelkie zmiany na obiektach domenowych dokonać w swoim kodzie i dopiero po wszystkim aktualizować stan bazy danych.

ORM potrzebny?

Niezależnie od architektury Twojego rozwiązania – monolit vs mikroserwisy – niezależnie od rodzaju bazy danych jaką przyjdzie Ci używać – SQL, NoSQL – nie da się jednoznacznie odpowiedzieć na pytanie czy będzie Ci potrzebny ORM/ODM (Object Document Mapper), czy nie. Nie da się jednoznacznie odpowiedzieć na pytanie które rozwiązań będzie Ci potrzebne.

To oczywiście zależy od Twoich potrzeb w projekcie. Inne potrzeby zaadresujesz używając LinqToSQL, inne używając EntityFramework.

Większość rozwiązań typu NoSQL nie implementuje konkretnego, ujednoliconego standardu, dlatego też nie ma konkretnego ODM do nich. W ogóle są budowane tak aby używać ich bez ODM.

Dobrym przykładem jest MongoDB, nierelacyjna dokumentowa baza danych w przypadku której nie używamy ORM ale ODM. Pełni taką samą funkcję jak ORM, czyli mapuje, ale nie relacje, a dokumenty.

Dlaczego o tym piszę

Zwracam na to uwagę bo, tak jak w przypadku każdego ORM czy ODM i każdej bazy danych, potrzeby i rozwiązania są inne.

Dlatego jasnym się staje, że Dapper nie jest dla każdego, zwłaszcza zważywszy na jego ograniczenia (chociaż są one celowe, bo Dapper jest budowany w konkretnym celu).

Zatem kiedy Dapper?

Wtedy kiedy chcesz w sposób łatwy wywołać zapytanie na bazie. Zależy Ci na szybkości i kontroli nad odwołaniami do bazy.

Wtedy.

Kiedy nie Dapper?

Otóż, nie wtedy kiedy chcesz aby ORM wygenerował model klas na podstawie encji.

Nie wtedy kiedy chcesz aby ORM generował zapytania do bazy za Ciebie.

Nie wtedy kiedy chcesz za pomocą ORMa śledzić zmiany na Twoim DB kontekście i potem je tylko łatwo „submitować”.

No i na pewno nie wtedy kiedy potrzebujesz mechanizmu który zgodnie z podejściem Code First wygeneruje za Ciebie migrację bazy danych bazując na Twoim modelu.

Nie do tego Dapper służy.

Kiedy ja używam Dappera?

Po pierwsze – pet project.

Rzadko kiedy w swoim pet project lub w przykładzie który realizujesz w ramach kursu czy workshopu, potrzebujesz skomplikowanych działań na bazie danych.

Bardzo często w ogóle nie potrzebujesz bazy danych, ale jeśli już ją masz to po co dodawać do projektu kobyłę taką jak nHibernate lub Entity Framework?

Dapper tu się świetnie sprawdzi.

Po drugie – części aplikacji które mają za zadanie tylko coś „czytać” z bazy. Zależy nam na jak najszybszym zaprezentowaniu danych. Dapper jest na prawdę szybki. W końcu to tylko lekka nakładka na ADO.NET.

Po trzecie – chcesz mieć pełną kontrolę nad tym jak wyglądają zapytania do bazy. W końcu z Dapperem sam je musisz napisać.

Czy Dapper to ORM?

Wracając do pierwotnego pytania. Czy Dapper to pełnoprawny ORM?

Tak! Jak najbardziej tak.

Ma plusy i minusy, jak każde rozwiązanie, ale robi to co prawdziwy ORM robić powinien. Mapuje obiekty na encje, mapuje obiektową strukturę na bazę danych.

Polecam się Dapperem pobawić. Proste przykłady i konfigurację znajdziesz w moim poprzednim poście – „Dapper – Czy mniej znaczy więcej?”.

Newsletter



Społecznościowe

Historycznie

Tagi