Simple.Data - rok później

Ponad rok temu, tj. w grudniu 2013 roku miałem okazję poznać nową bibliotekę, Simple.Data. Nawet zrobiłem nt. post na bloku w styczniu 2014 roku link. Teraz, po ponad roku komercyjnego używania tej biblioteki, mam na jej temat pewne przemyślenia, którymi chciałbym się podzielić.

Czym jest Simple.Data? Jest to jeden, z coraz popularniejszych "microORM", który łączy ze sobą zalety ORM, przy okazji nie narzucając zbyt dużo konfiguracji oraz "dodatkowych bajerów", które oferują tradycyjne ORM takie jak EF lub nHibernate.

Reklamowane zalety:
- szybkość aplikacji (szybszy dostęp do aplikacji)
- brak dodatkowej konfiguracji (biblioteka sama rozpoznaje nazwy tabel)
- mniejsza ilość kodu
- nowa, fajna składnia, wykorzystująca dynamic (np. db.highscores.FindAllByScore(2); )
- identyczna obsługa, dla wielu typów baz danych (włączając w to zarówno SQL jak i NoSQL)

Potencjalne wady:
- brak intellisense
- ewentualne problemy występuja dopiero w runtime

Tyle teorii, a teraz trochę praktyki:
- jak pokazuje prosty przykład (https://bitbucket.org/zchpit/sqlitesamples) Biblioteka Simple.Data jest ok 10 razy szybsza od EF (2500 ms vs 304 ms) jednak nadal ok 10 razy wolniejsza od klasycznego Data Reader (304 ms vs 17 ms).
- zaleta, w postaci automatycznego mapowania nazw tabel na nazwy obiektów nie zawsze się sprawdza, ponieważ często w istniejących bazach danych spotykałem się z polskimi nazwami tabel, a nazwy wszystkich zmiennych, klas, metod itp. w aplikacji wolę mieć po ang. więc... w pracy z istniejącymi rozwiązaniami i tak trzeba było wykonywać mapowanie
- inna składnia, która nie jest LINQ (fajny bajer, ale jednak wolał bym mieć również do dyspozycji również klasycznego LINQ)
- problem z aktualizacją modelu po zmianie na bazie danych, przez kogoś innego (np. administrator bazy danych)
- fajne, dla małych 1-2 os. aplikacji typu CRUD, które operują na małych bazach danych (np. 5-8 tabel)
- można zastosować dla baz, co do których mamy wątpliwości, czy zostaną obsłużone przez nHibernate lub EF.

Podsumowując, kiedy stosować, a kiedy nie stosować?


Nie stosować gdy:
- tworzymy duże rozwiązanie, przy którym będą niezależnie od siebie pracować programiści oraz BI. Brak możliwości automatycznego "update" modeli po stronie kodu, mocno utrudnia taką współpracę (choć oczywiście można się dogadać, co do używania procedur składowanych o niezmiennych parametrach).
- gdy najważniejszym parametrem jest szybkość działania aplikacji (nawet kosztem dłuższego czasu wytwarzania). W takich przypadkach lepszym rozwiązaniem będzie klasyczny Data Reader
- gdy pracujemy na istniejącej bazie danych, która w dodatku posiada polskie nazwy tabel, proc. składowanych itp. -> nieaktualne (patrz komentarz na końcu)
- gdy pracujemy na istniejącej, dużej bazie danych i spodziewamy się mnóstwa złączeń itp. W takich przypadkach jednak osobiście wolę wygenerować sobie Model automatycznie, mieć Intelii Sense oraz używać klasycznego LINQ a nie co chwila googlować jak to połączyć w nowej składni.

Kiedy stosować microORM
- gdy dostajemy do zrobienia od zera nową, stosunkowo małą aplikację typu CRUD, która ma pobrać dane z jednego źródła, przetworzyć je i zapisać gdzieś indziej np. z bazy X pobieramy naszych gości naszej super konferencji, z publicznego API pobieramy listę sankcyjną ludzi publicznie objętych zakazem wjazdu do UE, matchujemy obie listy, a wynik tego machowania zapisujemy do osobnej bazy danych.


Edit: od napisania tego posta, minął niecały tydź., ale miałem okazję bywać w kilku miejscach, więc mały update
a) O kwestie związane z aktualną bazą danych, na której mamy polskie nazwy tabel, a zmienne w aplikacji (viewModel), czyli "gdy chcemy mieć po ang. to czy musimy robić ręczne mapowanie?" zapytałem Maćka Aniserowicza (link do bloga) podczas spotkania Wrocławskiej grupy .NET i Maciek mi odpowiedział mega banalną odpowiedź (kurde, jak na to nie wpadłem, to sam nie wiem), tj.: pobierać dane z bazy za pomocą widoków, a w widokach nadawać zwracanym kolumnom ALIASY
b) Pod tym postem znalazłem komentarz Maćka Jędrzejewskiego, z ciekawości wszedłem na jego bloga i... znalazłem tam fajny "auto.mapper" o nazwie Slapper, za pomocą którego można automatycznie mapować typy "dynamic" zwracane przez Simple.Data na klasy naszego ViewModel -> link do posta na blogu Maćka

 Linki:
- Test wydajności mojego autorstwa
- Podst. solucję, którą wykorzystałem w moim teście pobrałem z bloga Tigran Gasparian
- Kody źródłowe Simple.Data na Github
- Porównanie kilku innych microSQL
- Link do bloga Maćka Jedrzejewskiego (automatyczne mapowanie obiektów do ViewModelu)