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)

AutoMapper

    Jednym z ćwiczeń praktycznych podczas "Zaawansowanego szkolenia z .NET 4.0" organizowanego przez Comarch (opis szkolenia tutaj), było napisanie własnego "AutoMappera" na kilka możliwych sposobów (refleksja, dynamic).
    A czym właściwie jest "AutoMapper"? AutoMapper to biblioteka, która udostępnia funkcjonalność automatycznego przepisywania wartości pól jednej klasy do drugiej. Potrzeba posiadania takiej funkcjonalności często zachodzi w sytuacji wykorzystywania w projekcie ORM. Zamiast pisać kod, służący do mapowania pól/właściwości z jednej klasy do drugiej, lepiej jest wykorzystać gotowe, darmowe rozwiązanie jakim jest AutoMapper, szczególnie, że jego wykorzystanie jest banalnie proste:

Najpierw, przed pierwszym użyciem tworzymy konfigurację mapowania (w jednym miejscu dla całego AppDomain). Najczęściej będzie to 'global.asax' lub 'bootstraper', ale może być też bezpośrednio przed metodą:

public static IMappingExpression<TSource, TDestination> CreateMap<TSource, TDestination>();
np.: Mapper.CreateMap<ClassA, ClassB>();

a nast. w kodzie produkcyjnym do mapowania wykorzystujemy metodę Map:

public static TDestination Map<TDestination>(object source);
np: ClassA classAB = Mapper.Map<ClassA>(classAA);  

//classAA will be copied to classAB and both will have values of classAA

Testowanie:
Najpierw musimy zainicjować konfigurację mapowania (np. poprzez wywołanie Bootstrapera), a nast. wywołać metodę:

Mapper.AssertConfigurationIsValid();

Linki:
Kod źródłowy znajduje się na github, a udost. jest na licencji MIT.
AutoMapper Getting-started
Artykuł na Visual Studio Magizne opisujący bardziej zaawansowane przypadki użycia: link

Simple.Data

Simple.Data, to nowy "ORM bez ORM", czyli nowy, mocno uproszczony sposób połączenia aplikacji z bazą danych. Sposób jest bardzo prosty, i pozwala na zaoszczędzenie linii kodu (im mniej tym lepiej), ale kosztem braku sprawdzania poprawności składni podczas kompilacji. Coś za coś. Dla małych, prostych aplikacji, ten ORM może być nawet sensowny, ale w dużych aplikacjach, z rozbudowanymi bazami danych, na których równocześnie pracuje wiele os. zwyczajnie się nie sprawdzi.

Dużo więcej, nt. tego ORM można przeczytać w art. na www.dobreprogramy.pl/. Tam też znajduje się mini tutorial dla tego rozwiązania (więc nie będę się powtarzał).

Rozwiązanie znajduje się na GitHub
Najłatwiej wersje "dla aplikacji" pobrać z NuGet
Dokumentacja z przykładami znajduje się: Simple.Data.Doc