Używanie DTO

Odpowiedz Nowy wątek
2015-07-27 11:43

Rejestracja: 9 lat temu

Ostatnio: 1 dzień temu

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 ?

Pozostało 580 znaków

2015-07-27 13:04

Rejestracja: 5 lat temu

Ostatnio: 5 dni temu

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

Pozostało 580 znaków

2015-07-27 13:10

Rejestracja: 5 lat temu

Ostatnio: 3 miesiące temu

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.

Czyli nie jest błędem jeśli w DTO dodam jakieś pola i będę na nich wykonywał działania żeby ustawić ich wartość? Pola, których nie ma w encji a do ustawienia wymagają korzystania z logiki biznesowej? - efem 2015-07-27 13:28
tak, to oczywiście nie jest błąd. - Tancerd 2015-07-27 13:47

Pozostało 580 znaków

2015-07-27 14:04
Moderator

Rejestracja: 16 lat temu

Ostatnio: 4 godziny temu

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.


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...
@Shalom ale to chyba tylko w transakcji? nie da się tego w hibernate ustawić? - karolinaa 2015-07-27 19:59
noo, w transakcji, potem obiekt jak wyleci z PC to staje się detach'ed - niezdecydowany 2015-07-27 20:02
@karolinaa niby tak, ale są tacy heretycy którzy forsują pomysł tzw "open session in view"... ;] - Shalom 2015-07-27 20:04

Pozostało 580 znaków

2015-07-27 14:19

Rejestracja: 12 lat temu

Ostatnio: 4 dni temu

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[...]_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.

o urwa! @Koziołek podlinkował do mnie, mogę umierać w spokoju. - niezdecydowany 2015-07-27 20:03

Pozostało 580 znaków

student pro 59b8d0d9
2015-07-27 17:50
student pro 59b8d0d9
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.

Pozostało 580 znaków

2015-07-27 19:38
Moderator

Rejestracja: 16 lat temu

Ostatnio: 4 godziny temu

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 ;]


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...

Pozostało 580 znaków

2015-07-27 19:52

Rejestracja: 12 lat temu

Ostatnio: 4 dni temu

0

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

transactional wyżej to tylko przykład ;) jest też taka abominacja jak "open session in view", a Spring nawet udostępnia gotowe zabawki które pozwalają z tego skorzystać ;] - Shalom 2015-07-27 20:07

Pozostało 580 znaków

student pro 59b8d0d9
2015-07-27 23:57
student pro 59b8d0d9
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 :)

Pozostało 580 znaków

Odpowiedz

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