Właśnie zacząłem od nowej pracy jako programista baz danych dla średniej wielkości firmy opartej na technologii Microsoft. Zauważyłem wcześnie, jak wiele praktyk różni się od tego, czego nauczono mnie w szkole w zakresie najlepszych praktyk, wzorców projektowych, testów i zarządzania projektami.
Najbardziej denerwuje mnie to, w jaki sposób nasz główny programista baz danych (odtąd zwany „John”) utrzymuje schemat modelu w bazie danych! Robimy to, mając 3 „magiczne” stoły; jeden dla schematów baz danych, jeden dla tabel i jeden dla kolumn.
Wstawienie rekordu do tabeli „ Tabele ” generuje (poprzez wyzwalacz bazy danych) rzeczywistą, odpowiednią tabelę. Wstawienie wiersza do tabeli „ Wiersze ” aktualizuje tabelę, do której istnieje odniesienie, z tym wierszem. Są one z kolei odczytywane przez jego domowy program w języku C # w celu wygenerowania modeli C #, które są używane przez programistów frontendów dla kontrolerów i na zewnątrz.
Poza tym większość prac rozwojowych odbywa się zgodnie ze środowiskiem ASP.NET MVC .
Widzę kilka wad tego podejścia:
- Potrzebujemy go do utrzymania ORM, a on rzadko ma na to czas (bezpieczeństwo pracy jest dobre!)
- Wyzwalacze dla tabeli „Tabele” i „Rzędy” są wadliwe. Nie obsługują aktualizacji tabel, ograniczeń Check ani bardziej „zaawansowanych” funkcji. Chociaż z pewnością moglibyśmy je ulepszyć, nie jestem jeszcze pewien, czy to jest właściwa droga.
- Utrzymywanie logiki programowej w bazie danych jest dziwne i restrykcyjne (chociaż możliwe jest rozszerzenie jego modeli przez C #).
- Jego generator modeli w języku C # musi być uruchamiany ręcznie przez jedną z 3 osób (wśród których jestem jedną z nich) i nie jest jeszcze wystarczająco dojrzały, aby włączyć się w proces automatycznej kompilacji.
Kilka osób zaproponowało wprowadzenie prawdziwego i przetestowanego produktu, takiego jak Entity Framework , ale odrzuca go, twierdząc, że utrzymanie logiki biznesowej w warstwie kodu jest odpowiednie tylko dla małych aplikacji i projektów bootstrapowych dla startupów.
Ten post prowadzi do czegoś, co mogłoby wyglądać na uprzejmą dyskusję, ale nie o to mi chodzi. Chcę tylko wyjaśnienia na temat naszego podejścia architektonicznego.
Czy utrzymywanie modeli domen w bazie danych może być trwałym rozwiązaniem dla rozwijającej się firmy?
źródło
Odpowiedzi:
Opisujesz wewnętrzną platformę.
Problem z wewnętrznymi platformami polega na tym, że na nowo wymyślasz wszystkie mechanizmy platformy lub technologii (w tym przypadku relacyjnej bazy danych), które zostały dopracowane i udoskonalone w ciągu dziesięcioleci ewolucji i wysiłku, ale źle je wynaleziono. Pomijasz wszystkie optymalizacje, które są dostępne dla tych, którzy wybierają bardziej konwencjonalny projekt, i handlujesz pierwotną prostotą i elegancją dla przyszłej złożoności i trudności.
To powiedziawszy, jeśli produktem końcowym tego procesu są prawdziwe tabele i prawdziwe klasy modelujące prawdziwe obiekty w domenie biznesowej, nie widzę większych szkód w tym podejściu, poza niedojrzałością narzędzi. Stack Exchange faktycznie używa własnej, własnej produkcji ORM, i wydaje się, że to zadziałało. Wiem więc, że tego rodzaju podejścia „wiejskie” mogą działać.
Zauważ, że większość ORM, które stosują podejście „najpierw do tabeli”, po prostu patrzy na strukturę tabeli w bazie danych, aby utworzyć klasy. Tabele „tabel” i „wierszy”, które utworzył twój przyjaciel, to jedynie metadane, które już istnieją w tabelach systemowych większości nowoczesnych systemów relacyjnych baz danych.
Dalsza lektura
Projekt „Wizja”, przestroga dotycząca efektu platformy wewnętrznej
(możesz pominąć preambułę i zacząć czytać w podtytule „Przedstawiamy wizję”)
źródło