Korzystanie z usług i DAO w kontrolerach mvc na wiosnę

Question

Buduję aplikację internetową, która przede wszystkim stanowi operację CRUD danych z zaplecza/bazy danych. Są przypadki, w których muszę napisać logikę biznesową (jestem pewien, że będziemy mieli więcej logiki biznesowej, kiedy będziemy się zagłębiać w rozwój). Aktualnie dla każdego tworzonego przeze mnie ekranu UI tworzę klasę modelu, klasę usługi, klasę DAO, kontroler (to w zasadzie serwlet) i mnóstwo stron jsp. W większości przypadków klasa usługi po prostu wywołuje metody z DAO, aby przekazać obiekty modelu. Zasadniczo używamy klas modeli do mapowania danych z ekranów interfejsu użytkownika. W związku z tym kontroler będzie zawierał obiekty modelu po przesłaniu formularza. Zacząłem używać klas usług, aby zachować warstwę separacji od warstwy internetowej do warstwy DAO. Czasem jednak wydaje mi się, że klasa serwisowa po prostu dodaje niepotrzebny poziom wywołań interfejsu API. Sądzę, że mógłbym wprowadzić DAO do kontrolera i wykonać to zadanie szybciej. Chcę korzystać z klasy usługi tylko wtedy, gdy jest wykonywana dodatkowa logika biznesowa. Jeśli musisz zaprojektować aplikację, jakie czynniki bierzesz pod uwagę przy korzystaniu z kontrolera-> DAO względem kontrolera-> Service-> DAO control flow?

Answer 1

DAO są bardziej szczegółowe i dotyczą jednej konkretnej jednostki. Usługi zapewniają funkcjonalność na poziomie makro i mogą skończyć z wykorzystaniem więcej niż jednego DAO. Zazwyczaj Usługi służą do definiowania granic transakcji w celu uzyskania atomowości. Innymi słowy, jeśli kończy się aktualizowanie wielu tabel przy użyciu wielu obiektów DAO, zdefiniowanie granicy transakcji w usłudze może pomóc w zatwierdzeniu lub wycofaniu wszystkich zmian wprowadzonych do bazy danych.

W swoim projekcie, ponieważ głównie robisz CRUD dla różnych podmiotów, może się wydawać, że usługi nie dodają dużo wartości. Jednak pomyśl o interfejsie internetowym jako sposobie aktualizacji danych. Korzystanie z usług pozwoli na udostępnienie tych samych funkcji, co usługa internetowa, później innym formom klientów, takim jak integratorzy zewnętrzni, itp.

Podsumowując, Twój projekt wydaje się być zgodny z konwencjonalnymi praktykami. Jeśli uważasz, że możesz łączyć wiele usług w jeden na podstawie jakiegoś wspólnego tematu, tak aby zredukować narzut kodu, to powinieneś to zrobić. Ostatecznym celem jest stworzenie możliwego do utrzymania kodu, którego nikt nie boi się zmieniać w razie potrzeby.

Answer 2

będę odwoływać się moja odpowiedź here

Długie i krótkie jest to zaletą korzystania z usługi warstwy jest to daje swobodę poruszania się w przyszłości, jeśli chcesz zrobić coś z wiosny Bezpieczeństwa i ról itp. Pozwala to na obsługę transakcji bardziej atomowo, a sama Wiosna ma naprawdę dobre adnotacje.

Answer 3

Skorzystaj z klasy usługowej, gdy masz do czynienia z więcej niż jednym aggregate root.

Wstrzykiwanie repozytoriów (zwane również dao, które zwraca kolekcję) lub dao bezpośrednio do kontrolera, bez potrzeby dodatkowej warstwy/klasy, aby uzyskać podstawowy dostęp.

Stosuj tylko klasy usług tam, gdzie to konieczne, w przeciwnym razie masz dwa razy tyle ile potrzeba.

Możesz utworzyć ogólne repozytorium i annoatoate z @Transactional(propagation = Propagation.REQUIRED), które wymusza transakcję, ale nie utworzy nowej, jeśli już istnieje. Więc jeśli później użyjesz wielu repozytoriów w jednej metodzie klasy usług, będziesz miał tylko jedną transakcję.

Answer 4

w Pro-Spring-3 książki są wymienione poniżej linii dla sterownika z JPA2

Once the EntityManagerFactory had been properly configured, injecting it into your service layer 
classes is very simple. 

i są one za pomocą tej samej klasy, obsługa i repozytorium, jak w poniżej:

package com.apress.prospring3.ch10.service.jpa; 
// Import statements omitted 
@Service("jpaContactService") 
@Repository 
@Transactional 
public class ContactServiceImpl implements ContactService { 
private Log log = LogFactory.getLog(ContactServiceImpl.class); 
@PersistenceContext 
private EntityManager em; 
// Other code omitted 
} 

, ale w przypadku, gdy zamierzasz korzystać z wiosennych danych CRUDRepository lub JPARepository, twój DAO będzie interfejsem i będziesz musiał utworzyć warstwę serwisową do obsługi twojego kodu