Witam,
Powiedzmy, że mamy tak:
Interfejs: UserDao
Implementację UserDaoImpl
I pytanie teraz czy z intefejsu UserDao powinno się korzystać bezpośrednio w kontrolerze czy stworzyć warstwę usług:
Interfejs UserService
Implementacja interfejsu: UserServiceImpl(tutaj wstrzyknąć UserDao i wywoływać odpowiednie metody). Pytam, ponieważ obecnie UserDao i UserService zawierają prawie to samo. Jak to powinno być poprawnie?
A co to za aplikacja? Bo przecież DAO pobiera tylko obiekty z bazy, nic więcej. Kontroler wywołuje akcje na warstwie logiki i zwraca obiekty do widoku. Więc jeśli u ciebie warstwa logiki "nic nie robi" to znaczy że albo napchałeś logikę do kontrolera (źle!) albo twoja aplikacja po prostu wyświelta dane żywcem z bazy...
jak @Shalom będzie krzyczał do sorki :P
U mnie w projekcie z guice jest tak:
Niewiem czy to dobre podejście ale u nas się sprawdza (site z 30-40tys userów).
@Biały Kaczor no dobra, ale gdzie sie coś DZIEJE z tymi danymi? Co wy wszyscy piszecie jakieś aplikacje Generic CRUD? :D Przecież w normalnych aplikacjach DAO i Kontrolery to jest 5% kodu, a cała reszta to jest logika aplikacji. A u was jej nie ma? :D
Też kiedyś pisałem generic krudy, ale potem zacząłem stosować architekturę nanoserwisów, moje diagramy urosły 4-krotnie i klienci są bardziej zadowoleni $$$ profit
O tym media milczą napisał(a):
Też kiedyś pisałem generic krudy, ale potem zacząłem stosować architekturę nanoserwisów, moje diagramy urosły 4-krotnie i klienci są bardziej zadowoleni $$$ profit
aha czyli jak mam problem z napisaniem aplikacji monolitycznej to wtedy rozpierdzielam ją na 100 mniejszych najlepiej w różnych językach programowania, bez transakcji, z logami w 100 miejscach z różnycmi mechanizmami monitorowania z 20 różnymi bazami i wtedy wszystko zaczyna działać...miodzio
W sumie tutaj też tak jest, patrząc na przykład z rozdziału 10.
http://helion.pl/ksiazki/spring-mvc-przewodnik-dla-poczatkujacych-amuthan-g,sprimv.htm#szczegoly