Co to jest ORM?

Który wybrać?

Piotr Wandycz

Takie pytanie nie powinno pojawić się na rozmowie kwalifikacyjnej, mimo to – warto znać na nie odpowiedź. Od juniora wymaga się dzisiaj, żeby z ORMa umiał korzystać, co tu komu po teorii? W znacznej większości przypadków pisane przez nas aplikacje wykorzystują bazy danych. A w najprostszych słowach ORM to sposób odwzorowania bazy danych w kodzie programu. Dzięki temu możemy wchodzić w interakcje z bazą – pobierać dane, dodawać dane itd. Nasz model w kodzie powinien dokładnie odwzorowywać relacje między tabelami. Tłumacząc skrót ORM otrzymamy “mapowanie relacyjno-obiektowe” (Object-Relational Mapping).

Na rynku .NETowym króluje od wielu lat Entity Framework, wypuszczony przez Microsoft. Rzadko spotyka się nHibernate czy LINQ to DB, więc polecam nauczyć się EF (jeśli jakaś firma korzysta z innego ORMa to przeważnie pojawia się jego nazwa w ofercie pracy). Jednak ORMów istnieje wiele, a dodatkowo pojawiły się też mikro ORMy. Każdy ma swoje zalety i wady określane tutaj ilością funkcji oraz szybkością. Spójrz przykładowo na tę tabelkę, porównującą wydajność różnych ORMów.

Entity Framework umożliwia nam wybranie jednego z trzech podejść: code-first, database-first albo model-first. Większość osób wybiera code-first, czyli napisanie kilku klas z modelem bazy, na podstawie których zostanie utworzona baza danych. Dochodzi tu dodatkowo zarządzanie migracjami, czyli poszczególnymi wersjami bazy. Migracja to taka klasa, mająca metodę Up (do zaktualizowania bazy) i Down (do cofnięcia jej zmian). Ja z kolei preferuję database-first, gdzie najpierw tworzę sobie bazę, a gdy mam wszystko po stronie bazy tak jak być powinno – jedną komendą generuję encje w kodzie. Gdy w przyszłości robię kolejne zmiany na bazie – znowu jedna komenda i mam odwzorowane w aplikacji. Jest jeszcze model-first, którego nie polecam. To projektowanie bazy z poziomu Visual Studio, poprzez plik EDMX. Niestety VS potrafi zacząć mocno przycinać jak EDMX rośnie.

Z bazami danych nierozłącznie związane jest pojęcie CRUDa. Operacje te możemy podzielić na dwie kategorie:

  • odczyt (Read) czyli query
  • zapis (Create, Update, Delete), czyli command

O ile EF świetnie radzi sobie z zapisem, bo jest prosty, bezpieczny, łatwo można zakładać transakcje itp., to do odczytu może nie być idealny. Nieoptymalne zapytania możemy zredukować, tworząc widoki na bazie, gdyż od paru lat można już mapować je na klasy. Lepiej mieć więcej kontroli nad JOINami niż zostawiać to frameworkowi. EF jest moim głównym wyborem, ale czasami dokładam do niego Dappera, jak zależy mi na prawie dwukrotnie szybszym odczycie. Ale więcej o Dapperze przeczytasz tu: Dapper – podstawy.

Ciekawą, ale pewnie bardziej podatną na błędy opcją jest stosowanie mikro ORM opartego na dynamic. Kilka lat temu popularny był Simple.Data, a teraz jest coś nowego, czemu będę musiał się dokładniej przyjrzeć – Mighty. Operując na konwencji, możemy dostać się do bazy danych. W Simple.Data przykładowo pisaliśmy taki kod:

User u = (User)db.Users.FindByNameAndPassword(name, password)

co przekładało się na SQLowy zapis:

SELECT * FROM Users WHERE Name = @p1 and Password = @p2

W momencie postawienia kropki za db traciliśmy podpowiadanie. Trzeba było podać nazwę tabeli lub widoku, a następnie FindBy i nazwy kolumn pokrywające się z tym co siedzi w bazie. Nie jest to zbyt wygodne, ale w jakimś nudnym i małym projekcie można by wykorzystać 🙂 Podsumowując jednym zdaniem: ORM odwzorowuje nam bazę danych w kodzie aplikacji oraz dostarcza nam zbiór metod (mniej lub bardziej wydajnych) do zmiany danych w bazie.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *