Współdzielenie DAL między projektami

Witam,

w pracy mamy dyskusję nad sensem wydzielania kodu ORM do współdzielonej paczki. Chodzi o encje + ich konfiguracje w Entity Frameworku.

Mamy dwie aplikacje pracujące na tej samej bazie danych, potencjalnie mogą się pojawić kolejne. Padł pomysł, żeby zamiast tworzyć mapowania ORM w każdym projekcie osobno, utworzyć paczkę, którą będziemy zaciągali w innych projektach.

Argumenty za:

• nie trzeba pisać dwa razy tego samego kodu
• tworząc nowy projekt od razu zaciągamy sobie wszystkie encje i na nich operujemy
• w przypadku zmian na bazie, poprawiamy w jednym miejscu, a w reszcie projektów sobie zaciągamy paczkę
• w przypadku migracji do wyższej wersji ORM, podbijamy wersję ORM w współdzielonej paczce, a w innych projektach tylko zaciągamy zmiany

Argument przeciw:

• problemy wynikające z jednoczesnej zmiany w dwóch aplikacjach, zmieniam coś w aplikacji A, kolega zmienia coś w aplikacji B. Musimy odpowiednio wersjonować paczkę, tak żeby nie blokować się wzajemnie, że nie można puścić aplikacji A, bo B jeszcze nie jest gotowa.
• częściowa utrata kontroli w projekcie nad warstwą dostępu do danych - chcę dodać jakąś encje, czy specyficzny konstruktor w danej encji i nie mogę tego zrobić w projekcie, tylko muszę stworzyć nową wersję paczki, a następnie zaktualizować ją w projekcie.
• podbicie zależności ORM w ramach współdzielonej paczki wymusza podbicie tej zależności w projektach zaciągających paczkę. Czyli wymuszona migracja do wyższej wersji.

W ogóle myślę, że kilka aplikacji robiących zmiany na tych samych tabelach w bazie to proszenie się o kłopot, bo sprowadza się to do stworzenia rozproszonego monolitu.

Jakie jest Wasze zdanie?

Dobrze myślisz. Dzielenie DAL między projektami zwykle nie kończy się dobrze. To będzie dodatkowa złożoność do utrzymania i jeszcze bardziej zawiłe zależności między projektami, tak samo testy i migracje. Już sam fakt, że dwie różne aplikacje modyfikują tę samą bazę jest podejrzany z perspektywy architektury i niesie kłopoty. Brnięcie w ten pomysł tylko ten stan pogorszy i dołoży wam roboty.
Aby z tego wyjść, możecie na przykład:

• wydzielić osobne bazy (nie zawsze się da),
• scalić aplikację w monolit (pracochłonne),
• postawić API które udostępni wspólne operacje (jeszcze bardziej pracochłonne, chyba że istnieje wyraźny stosunek wskazujący na to, która z aplikacji byłaby klientem).

Nie jestem dotnetowcem, ale mam złe wspomnienia z projektów gdzie wiele aplikacji pisało do wspólnej bazy danych. Zwykle kończy się to źle. (wyjątkiem jest tu oczywiście gdy mamy jedną aplikację biznesową, ale z powodów wydajnościowych rozbitą na dwie, jedną dedykowaną pod odczyt a druga pod modyfikacje)

Zwykle pewnym rozwiązaniem jest przykrycie takiej bazy kolejną aplikacją która nie ma logiki a tylko proxuje zapisy i odczyty?
Po co to? No bo kiedyś jak będziesz miał problem iż aplikacja A zapisuje dane a aplikacja B powinna sobie wtedy odświeżyć cache to zwyczajnie proxy bazy wysyła notifikacje do wszystkich co mają odświeżyć dane.
Pamiętaj też iż produkcyjna baza danych to zwykle największe barachło jeśli chodzi o refaktor. Pół biedy jak piszesz system działąjący od 8 do16 to wtedy zostajesz po pracy i migrujesz dane. Gorzej jak twój system działą 24/7 i wtedy często nawet pola z bazy nie można usunąć. Albo defaulta dla nowej kolumny dodać bo trwa to za długo

rakim napisał(a):

W ogóle myślę, że kilka aplikacji robiących zmiany na tych samych tabelach w bazie to proszenie się o kłopot, bo sprowadza się to do stworzenia rozproszonego monolitu.

To nie jest żaden kłopot, to po prostu zwykła katastrofa.
Ale za to potem jest o czym opowiadać przy piwie.

SkrzydlatyWąż napisał(a):

• wydzielić osobne bazy (nie zawsze się da),
• scalić aplikację w monolit (pracochłonne),
• postawić API które udostępni wspólne operacje (jeszcze bardziej pracochłonne, chyba że istnieje wyraźny stosunek wskazujący na to, która z aplikacji byłaby klientem).

• "wydzielic ..." : sklonowac baze da sie zawsze, problem potem z sync'kiem. Nie znam takiego narzedzia ktoremu ze spokojnym sumieniem, bez zadnej biezacej kontroli moznaby powierzyc automatyczna i cykliczna synchronizacje dwoch baz, nawet mysql'owych.
• "scalic ..." : a czym sie roznia wobec omawianego problemu, dwa rozne requesty wyslane przez dwa rozne klienty w tym samym czasie do monolitu na jednym serwerze, od tych samych requestow wysylanych do wydzielonych mikroserwisow?
• "postawic ..." : sytuacja wlasciwie identyczna do tej z monolitem.

Wlasciwie, teoretycznie to zadanie rewelacja dla szyny, ale praktycznie w 99,99% kolejka okazuje sie zbyt waskim gardlem. Nawet jesli operacje na poszczegolnych tabelach puszczane sa przez wydzielone kolejki, to najwieksze bezpieczenstwo daje wylacznie warunkowosc kazdej, tzn po potwierdzeniu zakonczenia poprzedniej, w przeciwnym przypadku kazdy pojedynczy strzal niesie za soba ryzyko kotla.

O ile wiem nikt jeszcze nie wymyslil na to dobrego rozwiazania i koczy sie to praca strazaka z workiem piachu i lopata w reku.

rakim napisał(a):

W ogóle myślę, że kilka aplikacji robiących zmiany na tych samych tabelach w bazie to proszenie się o kłopot, bo sprowadza się to do stworzenia rozproszonego monolitu.

Wydzielone tabele/bazy danych per mikroserwis, to nie jest jakas kategoryczna i niepodwazalna regula. To po prostu najbardziej korzystna, logiczna, ale wylacznie zwyczajowa praktyka pozwalajaca utrzymywac mikroserwisy w stanie zblizonym do optymalnego.

Czasami jest to jednak niemozliwe do uzyskania i trzeba sobie radzic w zaleznosci od aktualnego stanu rzeczy.
Decoupling mikroserwisow polega na separacji kodu i funkcjonalnosci a nie danych na ktorych ten kod i funkcjonalnosci operuja, stad tez wspolna baza i wydzielanie wspoldzielonej paczki okazuje sie nie tyle wyborem, ale niezalezna od naszego widzimise koniecznoscia. Sprawe ulatwia rowniez fakt, ze tak naprawde poza CRUD'em reszta operacji na bazie jest specyficzna dla okreslonych serwisow i rygorystyczna aktualizacja takiej paczki raczej rzadko jest powodem problemow - zwlaszcza jesli stosuje sie ze zrozumieniem "I" z SOLID.

Jak już tak robisz to chociaż zrób monorepo i dwie trzymaj w nim tego DALa i obie apki.