Projekt DML – czy da się uprościć CRUD ?

Cześć!

Na samym wstępie rozwinę skrót, który trochę może rozjaśni temat wpisu. Planujemy rozwój projektu Data Managment Library. Jego celem jest stworzenie biblioteki .NET która ma maksymalnie uprościć zarządzanie wpisami w bazie danych SQL jednocześnie zakładając zarządzanie schematem z poziomu SQL (SSMS), czyli jak w wielu projaketach – Database First. Domyślnie będziemy tworzyć aplikację webową jako front-endowy klient, ale celem następnym jest także stworzenie odpowiedniego interfejsu do wykorzystania np. w aplikacji WPF. Czy to ma sens ?

 

Znajdźmy sobie przykłady wykorzystania. Pomysł wziął się z pewnego projektu w którym to próbujemy doszlifować takie rozwiązanie (oczywiście celem nie jest samo rozwiązanie tylko dane w bazie) – w skrócie chodzi o to żeby zarządzanie i było możliwie łatwe ale sama baza jest odpowiedzialna za zarządzanie wieloma maszynami więc domyślnie jest projektowana tak aby była miejscem na składowanie logów, konfiguracji i wspierała wykonywanie operacji przez podłączone maszyny. Natomiast same zmiany konfiguracji maszyn powinny być „łatwiejsze” niż ciągłe pisanie skryptów SQL do czego przydaje się przygotowany interfejs użytkownika w którym można to łatwo wyklikać. Włączyć zadania, wyłączyć, zobaczyć co się wykonuje, przefiltrować błędy, ot takie bardzo proste duperele. Dla projektu ważna jest bezbłędna funkcjonalność bazy, a zarządzanie konfiguracją możliwie najprostsze – biorąc oczywiście pod uwagę że schemat z czasem może się zmienić…

A gdyby tak wydłubać sobie bazę, mieć jeden widok podłączyć się do serwera… i już móc to edytować ?

 

Oczywiście biorąc pod uwagę różne frameworki pierwsze co nasuwa wam się na myśl – Code First! Entity! Po co się pieprzyć skoro już ktoś to wymyślił!… Okej zgodzę się to wiele upraszcza – ale z punktu widzenia zarządzania czymś po „bardziej technicznej” stronie już niekoniecznie. DML niekoniecznie sprawdzi się w zastosowaniach gdzie nasz klient chciałby widzieć „Raport A”, „Raport B” a u nas w bazie mamy na to 13 tabel, 2 procedury i wszystko codziennie się przelicza, a jeszcze w tle pracuje jakiś program który ładuje jakieś śmieci do tych tabel. Ale już kiedy potrzebujemy kickstartu do projektu z bazą danych i obsłużyć głównie jakieś konfiguracje i wiemy że „klient” który to konfiguruje ma pojęcie co robi – będzie działać idealnie!

W projektowaniu DML zakładamy również, że nie musi być docelowym rozwiązaniem dla wszystkich tabel bo często bazy danych mają wiele specyficznych typów których nie da się jednakowo obsłużyć (np. ładowanie binarek do tabel czy też hash i salt do logowania) ale co do zasady można w całości oblecieć takim samym schematem. Na co nam w takim razie pisanie 20 widoków CRUD…

 

Zbudujmy więc projekt, który może się na starcie podłączyć do bazy danych, odpytać wszystkie schematy, stworzyć odpowiednie typy, konfiguracje a następnie wypluć ładny widok w którym będziemy mogli przeglądać każdą tabelę, szczegóły wpisu i edytować połączenia do innych obiektów. Ba – żeby było ciekawiej ale i prościej – nie będziemy używać pól o wdzięcznej nazwie ID! No bo przecież jak otworzę sobie taki widok i zobaczę „klient o id 7 należy do grupy o id 3 a chcę go przepiąć z Admin do User…” Możecie się nie zgodzić ale jestem zdania że w wielu przypadkach ID jest zbędne. Oczywiście nie wykluczam ID zupełnie ale jak już – to będzie on dotyczył tabel które rzeczywiście będą miały dużo wpisów i każdy z nich będzie istotny dla przykładu logi do konkretnych maszyn. No ale wtedy przecież ten ID nas nie interesuje bo jest tylko jakąś tam liczbą porządkową a istotna jest data i nazwa maszyny (znowu – nazwa a nie ID. Co mnie obchodzi że ma id 17424 jak wiem że nazywa się Domena12/Komputer7 – wtedy od razu wiem na której maszynie jest problem bez szukania jej we wpisach z maszynami). Co powiecie na taką koncepcję ? 😉

 

Jestem świadom że to o czym mówię nie jest najprostsze. Może też nie najlepiej to wytłumaczyłem i brzmi jak „magia, zrobię bibliotekę która zrobi wszystko za mnie”, ale kiedy dołożyć do niej pewne założenia i konfigurację jej działania to może przyśpieszyć każdy projekt z bazą danych o wiele roboczo godzin. Liczę że po zakończeniu prac wielu .NETowców będzie chciało z niego korzystać.