Czy modele domen w bazie danych mogą być trwałym rozwiązaniem?

13

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 tabeliTabele ” 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?

krystah
źródło
Modele domen są ściśle powiązane z projektowaniem opartym na domenie. Cały punkt projektowania opartego na domenie ma być wolny od projektowania opartego na danych, w którym dane (tj. Baza danych) stanowią rdzeń aplikacji. Wspomniane modele podejścia i domeny tak naprawdę nie pasują do siebie. Opracowując zgodnie z praktykami projektowania opartymi na domenie, nie obchodzi Cię, skąd pochodzą dane, po prostu je wykorzystujesz i logujesz je w warstwie biznesowej.
Andy,
Nie jestem pewien, co rozumiesz przez „utrzymanie logiki programowej w bazie danych”. Czy możesz to wyjaśnić?
Robert Harvey
Logika biznesowa w kodzie jest dokładnie właściwa. Baza danych powinna być głupim magazynem danych, niczym więcej.
Andy,
@I wydaje mi się, że to zależy. Być może ich DBA jest centrum zespołu, a on zachowuje całą logikę biznesową w bazie danych, która jest następnie odpytywana przez głupie przechowywane połączenia proc, wyodrębnia dane do POCO itp. Jest to wątpliwe podejście, ale znam zespoły, zachowując większość logiki biznesowej jeśli nie wszystko w DB.
Vladislav Rastrusny
@VladislavRastrusny Bez względu na przyczynę utrzymanie logiki biznesowej w bazie danych jest bardzo kiepskim projektem.
Andy,

Odpowiedzi:

16

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ę”)

Robert Harvey
źródło
2
Interesująca lektura, na pewno mógłbym narysować anologie. Nadal jestem nowy i na razie pozostanę widzem, ale na pewno będę go trzymał pod obiektywem. Dzięki za dobrą odpowiedź!
krystah