Edycja rekordów w bazie danych.

Cześć.
Piszę pierwszy raz apkę z użyciem Java+Spring+Hibernate. Będzie to aplikacja bazodanowa która przechowuje rekordy na temat pracowników.

Mam np obiekt Pracownik który przechowuje pola na temat osób zatrudnionych. Znajduje się tam m.in pole "Stanowisko".
W bazie znajduje się podobne pole które przechowuje stanowisko pracownika X.

A pytanie jest następujące. Czy w klasie Pracownik powinienem pisać metodę "zmienStanowisko" która będzie zmieniała stanowisko obiektu X i wysyłała do bazy zmieniony obiekt? Czy jednak w tej klasie nie powinno być nic takiego a jedynie w osobnej która odpowiada za połączenia z bazą danych i tam powinna być metoda "zmienStanowisko" która wysyła zapytanie do bazy aby zmienić stanowisko? Wydaje mi się że dużo bardziej wydajne jest drugie rozwiązanie ale wolałbym się upewnić ponieważ pierwszy raz będę używał hibernate+spring i nie wiem które rozwiązanie jest bardziej odpowiednie.

Pozdrawiam,
eL

Drugie. Pracownik to encja, zwykłe POJO. Za zmianę stanowiska odpowiada DAO dla encji Pracownik.
Dokładniej to powinien być Serwis pracownika, który ma jakieś dodatkowe operacje biznesowe (jeśli trzeba) i deleguje zadanie zmiany stanowiska do DAO pracownika.
Klasy powinny trzymać się zasady SRP - Single Responsibility Principle.

Wszystko jasne, dzięki bardzo!

Jeżeli jeszcze mógłbym odświeżyć na moment temat aby się upewnić.

Mam Klasę Pracownik.
Interfejs PracownikDao który zawiera metody CRUD
Klasę PracownikDaoImpl który implementuje powyższy interfejs.

I to w zasadzie rozumiem. Tylko teraz natknąłem się na tutorial który mówi jeszcze o serwisach: http://www.journaldev.com/3531/spring-mvc-hibernate-mysql-integration-crud-example-tutorial

Pytanie po co? Z tego co widzę interfejs PersonService zawiera dokładnie te same metody co PersonDao.
Później jest jeszcze PersonServiceImpl który i tak wykorzystuje metody napisane w PersonDaoImpl.

I na koniec pytanie, zawsze dla każdej Encji trzeba wykonywać aż 4 klasy? Tzn osobne Dao, osobne serwisy? W przypadku np 10 obiektów mam już aż 40 klas.

Serwisy mogą mieć dodatkową logikę biznesową. Np. gdy zwalniasz pracownika, to możesz sprawdzać w takim serwisie czy tak naprawdę ten pracownik istnieje, jeśli nie to możesz rzucić wyjątkiem. Dla prostych funkcjonalności wychodzi przeważnie, że Serwis deleguje zadania do DAO, prawie, że 1:1. Dodatkowo metoda serwisu może składać się z kilku metod DAO, wtedy transakcyjność łatwiej obsługiwać właśnie na metodach Serwisu.

Co do ostatniego pytania, no niby 40 klas ale są krótkie przecież i widzisz od razu jaką mają funkcjonalność zamiast przekopywać się przez jedną klasę z XXX metodami. Mając 10 encji i jedną klasę to zacznie Ci to wszystko puchnąć, gorzej będzie utrzymywać.

Jeśli większość klas DAO jest taka sama to możesz zainteresować się generycznym DAO - będziesz miał z góry zaimplementowane najprostsze operacje w swoim DAO i będziesz pisać tylko te, których w generycznym DAO nie można było obsłużyć.