Pracowałem z SpringMVC, Hibernate i niektórymi bazami danych na przykładzie aplikacji internetowej Java.
Jest kilka różnych, które to robią, ale ten samouczek integracji Spring 3 i hibernacji z przykładem ma klasę modelu, widok (w jsp) oraz klasy usługi i dao dla kontrolera.
Moje pytanie brzmi: czy zarówno usługa, jak i klasy DAO nie robią tego samego? Dlaczego miałbyś ich potrzebować?
To był samouczek, którego faktycznie używałem : http://fruzenshtein.com/spring-mvc-security-mysql-hibernate/
Odpowiedzi:
Zasadniczo DAO jest tak lekki, jak to możliwe i istnieje wyłącznie w celu zapewnienia połączenia z bazą danych, czasami jest abstrakcyjny, aby można było użyć różnych backendów bazy danych.
Warstwa usług ma zapewniać logikę działania na danych wysyłanych do i od DAO i klienta. Bardzo często te 2 elementy zostaną zebrane razem w ten sam moduł, a czasami w ten sam kod, ale nadal będą postrzegane jako odrębne logiczne jednostki.
Innym powodem jest bezpieczeństwo - jeśli udostępniasz warstwę usługi, która nie ma związku z bazą danych, trudniej jest uzyskać dostęp do bazy danych od klienta, chyba że za pośrednictwem usługi. Jeśli dostęp do bazy danych nie jest możliwy bezpośrednio z klienta (i nie ma trywialnego modułu DAO działającego jako usługa), wówczas atakujący, który przejął klienta, może próbować zhakować warstwę usługi, zanim uzyska wszystko oprócz najbardziej oczyszczony dostęp do twoich danych.
Jestem pisarzem danego postu. Mam swój uczciwy udział w pracy nad różnymi technologiami i różnymi architekturami. Na podstawie powyższego mogę śmiało powiedzieć, że posiadanie warstwy usługi i warstwy dao jest zawsze dobrym pomysłem. DAO powinno być ograniczone do dodawania / aktualizacji / wstawiania / wybierania obiektów encji do / z bazy danych i to wszystko. Jeśli chcesz zrobić coś więcej pod względem logiki, dodaj to do warstwy usługi. Pomoże to uczynić kod modularnym i łatwym do zastąpienia po wymianie bazy danych (dla pewnej części danych). Ma to szczególne zastosowanie w aplikacjach zawierających raporty, które mają ciężką logikę nawet po pobraniu danych z bazy danych.
Również wiosną bezpieczeństwo jest idealnie stosowane w warstwie serwisowej. Nie chciałbyś tego zmienić.
Adam Bien podkreśla w swojej książce, że JPA EntityManager jest dobrą uniwersalną implementacją DAO:
W świecie Java EE prawie nigdy nie ma potrzeby pisania własnego DAO, ponieważ zawiera on implementacje JPA. Musisz tylko napisać warstwę usługi.
Wdrożenie własnej warstwy DAO jest naprawdę kacem z bardzo słabej architektury J2EE sprzed 15 lat, ale wiele osób nadal czuje się do tego zmuszonych. Te niestandardowe warstwy DAO często zapewniają jedynie funkcje przekazywania, które wywołują odpowiednią metodę w EntityManager.
Aby odpowiedzieć na twoje pytanie, tak, potrzebujesz warstwy usługi i DAO, ale musisz tylko napisać warstwę usługi.
Zazwyczaj umieszczam cały kod specyficzny dla bazy danych (zapytania) w DAO oraz obsługę transakcji i logikę biznesową w usługach. Pozwala to metodom serwisowym wywoływać metody na wielu serwerach dao i zachować je w ramach tej samej transakcji. Moim zdaniem pozwala to na lepsze wykorzystanie kodu w dao.
Przekonałem się, że warstwa usługi w większości przypadków powoduje niepotrzebną złożoność. Teoretycznie należy unikać logiki biznesowej w warstwie dao, ale ostatecznie prowadzi to do zamieszania, nawet niektórzy ludzie nie chcieli całkowicie usunąć warstwy dao, ponieważ uważają, że nie wnosi ona wartości dodanej. http://ayende.com/blog/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer
Ale jeśli masz wiele logiki biznesowej, to tak. To dobry pomysł. Jak ważne jest stworzenie warstwy usługi?
IMHO warstwę usługową można uznać za warstwę między kontrolerem a warstwą DAO. Ta warstwa usługi jest dokładnie tam, gdzie możemy dodać logikę biznesową, a nawet stworzyć obiekt zwrotny specyficzny dla tego, co ma być renderowane przez widok.