Odkąd poznałem Entity Frameworka prześladuje mnie pytanie baza czy aplikacja, gdzie trzymać logikę po stronie bazy czy po stronie aplikacji. Do tej pory nie znalazłem na to  jednoznacznej odpowiedzi. Przypomniałem sobie o tym moim wewnętrznym konflikcie przy okazji mojej aplikacji do rozsyłania masowych mejli, korzystam przy maratonie rowerowym. Akurat w tej aplikacji nie ma za bardzo logiki po stronie bazy bo baza służy tylko i wyłącznie do przechowywania informacji, a cała logika jest po stronie aplikacji (tzn wysyłanie mejli i przygotowanie danych) .

Tak na marginesie jest artykuł Rafała Hryniewskiego na devstyle o tytule ORM czy SQL, polecam przeczytać.

Od samego początku mojej przygody z programowaniem, tj od zakończenia studiów i pracy dyplomowej w której uczyłem się c#, pracowałem z danymi i bazą w tedy wiedza na temat baz była znikoma. są tabel e w których przechowywane dane i prostymi zapytaniami można się do nich dostać. Korzystałem w tedy z Visual Studio 2005 a do połączenia służył ADO.Net, pamiętam, że wrzucało się na formę DataSeta, łączyło się z bazą diagram tabel generował się podobny do EF. Z tym narzędziem długo nie popracowałem było strasznie toporne, brat (młodszy) pokazał mi lepsze rozwiązanie czyli tworzenie własnych klas odwzorowujących strukturę tabel, z których robiło się listy List<klasa>. Żeby to wypełnić korzystałem z SQLCommand w którym wywoływałem z reguły procedurę składowaną (potem też zapytanie sql), wynik generował się do obiektu klasy DataTable który to obiekt mapowałem na obiekt typu List<> . Te listy stanowiły źródło do wszelkich gridów, filtrów (combobox-ów) i innych pól. Nie znałem Entity Frameworka, a praca z takimi klasami, wymagała poświęceniu temu dużo czasu szczególnie jeżeli baza się zmienia, trzeba pamiętać o zmianach.  Z takim modelem pracowałem aż poznałem EntityFrameworka, a nawet jak go znałem to łączyłem EF-a z SQLCommand i procedurami składowanymi.

W mojej pracy panuje przekonanie, że aplikacja służy tylko do wyświetlenia danych, to baza odpowiedzialna jest za całą logikę, w skrajnych przypadkach nawet za weryfikację danych. W reszcie świata panuje przekonanie odwrotne baza służy tylko do przechowywania danych a cała logika jest po stronie aplikacji.

Ja po kliku latach doświadczeń doszedłem do wniosku, że wszystko zależy do czego to mamy wykorzystać (wszystko zależy od kontekstu), mamy teraz ORM-y które ułatwiają nam pracę z bazą wręcz zastępują nam bazę danych same potrafią ją wygenerować (podejście code first EF), można zmapować istniejącą bazę (podejście base first EF), można w prosty sposób dodawać, usuwać, aktualizować rekordy, można w prosty sposób łączyć tabele  ze sobą i pisać zapytania bez znajomości SQL-a (linq i lambda) i można się na prawdę wściekać kiedy EF nie potrafi zmapować widoku bo brakuje w nim klucza głównego albo gdy po podmianie baz wywala jakiś niezrozumiały wyjątek.

Wracając do mojej aplikacji , EF mnie zawiódł, coś nie zadziałało przy mapowaniu tabel, nie chciałem się nad tym zastanawiać ( nie było czasu) za późno się rozpoczołem rozsyłanie życzeń świątecznych, napisałem połączenie z bazą w starym dobrym sqlcomand to mnie nie zawiodło. Wiadomości wszyscy otrzymali.

Pytanie pozostało logika po stronie aplikacji czy bazy?

Kategorie: ArchiwumInne