Używanie DTO

0

Czy w przypadku kiedy moja metoda zwraca employee przy np. dodawaniu, lub znajdowaniu powinienem zwracać obiekt DTO zamiast tego co mam teraz ?

 
@Override
	public Employee findEmployeeById(int id) {
		Employee employee = employeeRepository.findById(id);
		return employee;
	}
 
@Override
	public Employee addNewEmploye(Employee employee) {
		
		employeeRepository.save(employee);
		return employee;
	}

Te metody powyżej są z serwisu w @RestController mam

 
@RequestMapping(value="{id}/findEmployee",method=RequestMethod.GET)
public Employee findEmployeeById(@PathVariable int id){
	
	return employeeService.findEmployeeById(id);
	
}

to juz bedzie pokazane w przegladarce wiec moze w tym miejscu należy zastosować conwersje na DTOEmployee ? Czy wzorzec DTO jest popularny i czesto uzywany ?

0

Jak nie masz potrzeby to nie używaj. Wzorce to nie są produkty w sklepie które sobie bierzesz bo ...chcesz, one rozwiązują pewne klasy problemów, masz problem -> możesz go rozwiązać za pomocą wzorca.
Wpychanie wzorców na siłę jest bezsensu

2

Patrząc zasób zwracasz jsonem / xmlem i nie chcesz żeby to była surowa encja z bazy danych, a zwrapowana / z dodatkowymi polami wyliczonymi dynamicznie to używasz dto. Jeżeli Ci to wisi to dto nie jest konieczne.

0

Ja bym uważał ze zwracaniem obiektów encyjnych z/do widoku i w ogóle z przekazywaniem ich w różne miejsca. Bo musisz pamiętać że dopóki sesja jest aktywna każda zmiana obiektu encyjnego będzie automatycznie persystowana! Ludzie często o tym zapominają a potem nie mogą zrozumieć czemu im sie jakieś dziwne rzeczy dzieją w bazie. Jeśli koniecznie chcesz to proponuje robić detach na takich obiektach żeby mieć pewność że nie spowodują żadnych zmian w bazie.

2

To zależy co masz w klasie Employee. Przykładowo:

class Employee {

    Collection<Project> projects;

}

Wysłanie bezpośrednio encji spowoduje, że serializowana będzie też kolekcja projektów, które mogą zawierać np. referencje do dokumentacji w plikach :D Rozwiązania tego problemu są trzy:

  1. Własny serializer. W przypadku zwykłych encji nie ma to sensu. Własne mechanizmy serializacji pisze się w pewnych konkretnych przypadkach.
  2. Widoki JSON, czyli użycie adnotacji @JsonView lub podobnej (ta jest z Jacksona) w celu wskazania, które pola są serializowane w ramach którego widoku. Jest to bardzo fajne rozwiązanie ponieważ automat skojarzy pole z żądanym widokiem i wykona odpowiednie "rzutowanie" (w rozumieniu rysunku technicznego, a nie obiektowym). Wadą jest możliwość stworzenia "annotation hell" gdy jedna klasa ma wiele różnych widoków. Kod staje się wtedy nieczytelny, bo poszczególne pola są "przyozdabiane" długimi litaniami adnotacji.
  3. DTO i odpowiedni konwerter. http://4programmers.net/Forum/Java/255636-dto_-_przyklad_zastosowania_w_spring?p=1160666#id1160666 masz przykłądowe rozwiązanie ze springa.

Teraz problem otrzymywania encji od klienta. Podobnie jak w poprzednim przypadku masz możliwość użycia odpowiednich adnotacji albo DTO.

0
Shalom napisał(a):

Ja bym uważał ze zwracaniem obiektów encyjnych z/do widoku i w ogóle z przekazywaniem ich w różne miejsca. Bo musisz pamiętać że dopóki sesja jest aktywna każda zmiana obiektu encyjnego będzie automatycznie persystowana! Ludzie często o tym zapominają a potem nie mogą zrozumieć czemu im sie jakieś dziwne rzeczy dzieją w bazie. Jeśli koniecznie chcesz to proponuje robić detach na takich obiektach żeby mieć pewność że nie spowodują żadnych zmian w bazie.

Dokładnie. Można też (zamiast detaczować- bo np. chcemy aby encja była zapisana w bazie) zwracać encje z metod które rozpoczęły transakcję, bo po jej zakończeniu encje i tak będą 'detached'. Gorzej jest z trybem extended, bo tam trzeba by manualnie kopiować encje.

0

@student pro 59b8d0d9 to nie zawsze zadziała bo ktoś sprytnie może sobie odpalić transakcje "wyżej" i będzie ją propagował na dół, w efekcie tobie sie wydaje że zwracasz encje z metody @Transactional i że na bank będzie w tej chwili odpięta, a w rzeczywistości metoda wołająca twoją metodę też jest @Transactional i twoja encja nadal jest dopięta to bazy ;]

0

@Shalom, ale od tego jest odpowiednia kompozycja warstw kontroler>serwis>DAO i analiza statyczna, która będzie krzyczeć na @Transactional w kontrolerze.

0
Shalom napisał(a):

@student pro 59b8d0d9 to nie zawsze zadziała bo ktoś sprytnie może sobie odpalić transakcje "wyżej" i będzie ją propagował na dół, w efekcie tobie sie wydaje że zwracasz encje z metody @Transactional i że na bank będzie w tej chwili odpięta, a w rzeczywistości metoda wołająca twoją metodę też jest @Transactional i twoja encja nadal jest dopięta to bazy ;]

To zawsze możesz sobie założyć REQUIRES_NEW :)

1 użytkowników online, w tym zalogowanych: 0, gości: 1