ServiceLayer w Springu mvc funkcjonuje w ten sposób, że odwołujemy się do niej w Controller zamiast bezpośrednio do warstwy DAO gdzie po drodze wykonujemy wszystkie operacje tzw. logiki biznesowej.
Np. metoda w EmployeeServiceImpl
addEmployee(Employee { // tutaj wrzucam wszystko co chcę zrobić po drodze, // this.employeeDAO.addEmployee(e) }
Ma za zadanie jedynie odciążyć Controller i DAO ze zbędnych metod czyt. wszystkiego co nie jest związane z obsługą bazy danych i generowaniem widoków, czy tak?
@DonPablito: service layer to po prostu jeden ze wzorców enterprise, służy do rozdzielenia klienta i db, dodatkowo też trzyma strukturę warstwową, nie zobaczysz sensu tego czegoś, póki nie wsiądziesz do dużego projektu, gdzie takie warstwy są potrzebne choćby dla przejrzystości
no i dwa, tak jak napisałeś, jak już jest ten service layer to umieszcza się w nim logikę biznesową, dao zostawiając w spokoju
@DonPablito: chodzi mi o to, że service jest w wielu przypadkach patologią, którą wiele osób tworzy tylko po to, że: a) było tak w tutorialu b) chcemy być "enterprise" i dodaje sobie warstwę, która nic nie robi tylko opakowuje dao/repository i wywołuje z niej pojedyncze metody
@Eoghan: Ale ja właśnie w takiej sytuacji jestem :) i nie chce być "enterprise" tylko próbuje zrozumieć jak to MVC działa, dlatego korzystam z cudzych wzorców.
@DonPablito: Podstawowe MVC ogranicza się do tego, że masz model (model danych + logika biznesowa), kontroler i widok. Często wystarczy Ci coś w stylu: Employee EmployeeRepository / dao EmployeeController i do tego widok Repository wstrzykujesz do kontrolera, w nim pobierasz/zapisujesz dane i tyle. W takiej sytuacji niektórzy jednak utrudniają sobie życie robiąc coś takiego, że masz zamiast tego: Employee (np. encja JPA) EmployeeRepository / dao EmployeeService EmployeeController Gdzie w warstwie serwisu
@Eoghan: W moim przypadku ja nie mam wątpliwości i wiem że warstwa serwisowa tylko mi przeszkadza. Zacząłem jednak pisać aplikację wg tego wzorca i już nie widzę potrzeby jej upraszczać.
Mniej więcej zdawałem sobie sprawę z tego co wyżej napisałeś i chciałem się upewnić co mogę wrzucić do serwisu, bo trochę tej logiki jednak będę miał. A jak zauważyłeś wcześniej do tej pory miałem tylko odwołanie do kolejnej metody i tak
@DonPablito: koszt wyekstrahowania interfejsu z rzeczywistej implementacji, gdy jest to potrzebne, jest tak minimalny, że wolę to robić jak już jest konieczne.
ServiceLayer w Springu mvc funkcjonuje w ten sposób, że odwołujemy się do niej w Controller zamiast bezpośrednio do warstwy DAO gdzie po drodze wykonujemy wszystkie operacje tzw. logiki biznesowej.
Np. metoda w EmployeeServiceImpl
addEmployee(Employee {
//
tutaj wrzucam wszystko co chcę zrobić po drodze,
//
this.employeeDAO.addEmployee(e)
}
Ma za zadanie jedynie odciążyć Controller i DAO ze zbędnych metod czyt. wszystkiego co nie jest związane z obsługą bazy danych i generowaniem widoków, czy tak?
#spring #java #naukaprogramowania
no i dwa, tak jak napisałeś, jak już jest ten service layer to umieszcza się w nim logikę biznesową, dao zostawiając w spokoju
a) było tak w tutorialu
b) chcemy być "enterprise" i dodaje sobie warstwę, która nic nie robi tylko opakowuje dao/repository i wywołuje z niej pojedyncze metody
Employee
EmployeeRepository / dao
EmployeeController
i do tego widok
Repository wstrzykujesz do kontrolera, w nim pobierasz/zapisujesz dane i tyle. W takiej sytuacji niektórzy jednak utrudniają sobie życie robiąc coś takiego, że masz zamiast tego:
Employee (np. encja JPA)
EmployeeRepository / dao
EmployeeService
EmployeeController
Gdzie w warstwie serwisu
Mniej więcej zdawałem sobie sprawę z tego co wyżej napisałeś i chciałem się upewnić co mogę wrzucić do serwisu, bo trochę tej logiki jednak będę miał. A jak zauważyłeś wcześniej do tej pory miałem tylko odwołanie do kolejnej metody i tak
http://softwareengineering.stackexchange.com/questions/159813/do-i-need-to-use-an-interface-when-only-one-class-will-ever-implement-it