Spring - kilka pytań o zwyczaje

Niedawno przerobiłem pewien kurs spring boot'a, w którym autor zaintrygował mnie pewnymi sposobami tj np.:

1. wypisywanie w @RequestMappowaniu, że 'produces = MediaType.APPLICATION_JSON_UTF8_VALUE' lub 'consumes = MediaType.APPLICATION_JSON_UTF8_VALUE'
   **- czy to nie jest zbędny kod w przypadku takich wartosci?
   **
2. zwracanie każdej odpowiedzi poprzez ResponseEntity < > ()
   **- rozumiem, ze istotne jest wysyłanie poprawnych odpowiedzi HTTP, ale czy powinno sie tego używać przy każdym przypadku?
   **
3. tworzenie dwóch repozytoriów, które zwracają ten sam typ obiektu tj.

public interface PageableRoomRepository extends PagingAndSortingRepository<RoomEntity, Long> {
    Page<RoomEntity> findById(Long id, Pageable page);
}

oraz

public interface RoomRepository extends CrudRepository<RoomEntity, Long>{
    RoomEntity findById(Long id);
}

**- czy jest coś co przemawia za tworzeniem takiego rozwiązania zamiast wrzucenia tego do jednego repo?
**
4) tworzenie konwertera dla każdej encji np.

public class ReservationEntityToReservationResponseConverter implements Converter<ReservationEntity, ReservationResponse>

**- rozumiem sens tworzenia takiego czegoś gdy obiekt, który chcemy wystawić różni się od obiektu 'oryginalnego' bo np. pomijamy jakieś pole ale nie za bardzo wiem czy powinno się tworzyć konwertery w przypadku gdy to 'obiekt docelowy' jest identyczny z 'obiektem zródłowym' **

Byłbym wdzięczny za rozwianie moich wątpliwości :)

1.Masz racje, na ogół te adnotacje nie sa potrzebne
2.Ja używam @ResponseStatus jak zwracam cos co nie jest 200 i tyle
3.Bez sensu jak dla mnie robienie 2 intefrejsów
4.To jest bardziej złożona kwestia ale konwerter dla każdej encji też bez sensu

1. Podanie konkretnego consumes i produces zawęża ci możliwe przyjmowane typy. Jeśli podasz JSON, to nie możesz wysłać lub zwrócić danych w formacie XML.
2. Używając ResponseEntity masz możliwość zwrócenia np. nagłówka czy statusu odpowiedzi.
3. Różne repozytoria udostępniają inne metody. Np. PagingAndSortingRepository udostępnia metody findAll(Pageable pageable), findAll(Sort sort). Poza tym PagingAndSortingRepository dziedziczy z CrudRepository, więc nie ma potrzeby tworzenia osobnych repozytoriów.
4. Raczej należy "przekonwertować" encje na jakiś obiekt DTO przed zwróceniem z kontrolera. Nawet jeśli DTO jest identyczne jak encja. Jednak tworzenie dla każdej encji nowej klasy do konwertowania to przesada.

Jonki1997 napisał(a):

1. Raczej należy "przekonwertować" encje na jakiś obiekt DTO przed zwróceniem z kontrolera. Nawet jeśli DTO jest identyczne jak encja.

Dlaczego?

jarekr000000 napisał(a):

Jonki1997 napisał(a):

1. Raczej należy "przekonwertować" encje na jakiś obiekt DTO przed zwróceniem z kontrolera. Nawet jeśli DTO jest identyczne jak encja.

Dlaczego?

Będzie faktycznie potrzebował się odspawać to jskieś DTO lub wrappera wprowadzi. Dopiero wtedy. YAGNI

A skąd będzie wiedział, że ma się odseparować? Ktoś po prostu rozszerzy obiekt, będąc przekonanym, że obiekty wewnętrzne są odseparowane. To już chyba nie jest YAGNI, tylko próba zaoszczędzenia 5 minut dziś kosztem 5 godzin pojutrze.

Poczytałem jeszcze o Yagni (zaczynam od Fowlera jak jest taka możliwość) i co widzę?

Yagni is not a justification for neglecting the health of your code base.

Yagni only applies to capabilities built into the software to support a presumptive feature, it does not apply to effort to make the software easier to modify.