Scenariusz:
- Stos: Java, Spring, Hibernacja.
- Model: aplikacja klient-serwer.
- Wzór: Model-View-Controller (MVC).
Klasy warstwy usług mają trzy zachowania:
Niektóre usługi zawierają regułę biznesową w ramach metod i delegują trwałość aplikacji. Lubić:
EntityManager.save (encja);
Niektóre usługi po prostu wywołują funkcję bazy danych (przekazują parametry), takie jak:
CallableStatement cls = con.prepareCall („{call databaseFunction (args)}”);
Niektóre usługi mają metody z oboma zachowaniami.
Moje pytania:
- Czy istnieje problem z wywoływaniem funkcji baz danych bezpośrednio przez aplikacje? Czy nie jest to uważane za złą praktykę? Jaki byłby model architektury mający zastosowanie do takiego projektu?
- Czy jest jakiś problem z mieszaniem zachowań w tej samej usłudze? Takie jak transakcje i spójność?
- Czy w przypadku konserwacji enkapsulacja sprawia, że programiście nie jest w stanie zmienić funkcji w bazie danych? Jak tego uniknąć?
- Czy ten scenariusz zdarza się w innych aplikacjach na całym świecie, czy był to tylko błąd architektoniczny?
design-patterns
architecture
mvc
code-quality
linuxunil
źródło
źródło
Odpowiedzi:
Myślę, że jest. Umieszczasz wiedzę o wewnętrznych elementach bazy danych w usłudze aplikacji. Zmiana bazy danych w jakikolwiek sposób (zmiana silnika pamięci, a nawet zmiana nazwy pola lub utworzenie indeksu) może wymagać zmiany usługi aplikacji, co narusza SRP .
Zobacz komentarz poniżej.
Nie wierzę, że jest problem techniczny, ale jest logiczny. Po prostu łączysz dwa podejścia w aplikacji, dzięki czemu jest niejasna, mniej ustrukturyzowana, trudna do dostosowania do zmian. Zobacz powyższe komentarze dotyczące naruszania SRP.
Jasne, że tak.
Umieść metody i funkcje bezpośrednio działające z bazą danych na osobnym poziomie abstrakcji (czy to warstwa DAO, czy prosty wzorzec repozytorium - zależy od złożoności aplikacji)
Myślę, że w naszym świecie wszystko się dzieje;)
źródło
Zgodnie z tym, co powiedziałeś, istnieje warstwa usługi, więc wzór architektoniczny, który wydaje się odpowiedni, to architektura warstwowa. Dalsze informacje
Tak, zwykle złą praktyką jest wykonywanie bezpośrednich wywołań bazy danych na innej niż warstwa dostępu do danych, w ten sposób warstwa biznesowa ma dostęp tylko do abstrakcji bazy danych.
Jeśli chodzi o zachowania związane z mieszaniem, użycie pewnego wzorca projektowego jako wzorca DAO lub wzorca repozytorium może pomóc w delegowaniu tych obowiązków, poprawiając tym samym kod.
Jedną z zalet korzystania z wzorca projektowego i ORM jest czytelność kodu i hermetyzacja obowiązków, więc jeśli dostęp do bazy danych ulegnie zmianie, warstwa biznesowa nie powinna się wiele zmienić.
źródło