Tworzenie struktury modelu do mapowania na Json. Jaka praktyka lepsza?

Cześć. Mam wątpliwości odnośnie dobrej praktyki zagnieżdżania obiektow podczas mapowania Jsonów na Obiekty i na odwrót. Chodzi o przypadek kiedy struktura jest trochę bardziej żłożona, sa w niej listy, obiekty wewnątrz, którcyh sa listy. Bardzo ogólnie:

public class Json {
    private String name;
    private String Surname;
    private List<FamilyMember> family;
    private Contact contact;
    // getters, setters
}

Mam watpliwośći jak jest "czyściej" jesli np dany obiekt "Json" przychodzi z jakiegoś Api do naszego backendu, od razu go przetwarzamy i odsyłamy gdzieś dalej np. do naszej apki fontowej, lepiej jest zagnieżdzożone obiekty tworzyć jako klasy wewnetrzne tego Jsona:

public class Json {
    private String name;
    private String Surname;
    private List<FamilyMember> family;
    private Contact contact;

    class FamilyMember {
    private String name;
    private int phone;
    
    // getters, setters
    }
    // getters, setters
    // itd ....
}

czy jako zewnętrzne klasy i zagnieżdzać je jako pola tylko? W przypadku klas wewnętrznych to razem ze wszystkimi geterami i seterami to struktura robi się olbrzymia i ciężko się ten model czyta, w przypadku klas zewnętrznych czasami klasy będa tworzone tylko po to aby umieścić je w jednym polu. Z drugiej strony chęć skorzystania z typu lasy wewnętrznej wymagałaby łańcuchowego odniesienia do typu co też jest śmierdzące... Jakie zatem wasze zdanie?
P.S. używam jacksona 2

U nas w projekcie mamy osobne klasy na każdy z typów, które gdzieś tam w requestach się pojawiają. Myślę, że pomysł z klasami wewnętrznymi jest bardziej problematyczny.
Co do getterów/setterów czemu nie użyjesz lomboka? Wtedy taka klasa składa się praktycznie tylko z pól.

@Waleq: tak lombok jest opcją, mimo to jakoś go nie lubie, może muszę się przekonać do niego

Ja tam z własnego doświadczenia poleciłbym ci do każdego modelu mieć osobne DTO. W takim DTO jak masz jakieś rozbudowane pole, to po prostu jego id wpisujesz (zakładając że gdzies przetrzymujesz te dane modelowe), potem jakiś mapper co zmapuje DTO na obiekt modelowy, i już obiekt modelowy poddajesz walidacji logicznej - tak z grubsza

@Pinek w tym przypadku encji nie ma przychodzi model z api zewnetrzengo jest przetwarzany i idzie dalej

Prędki_Lopez napisał(a):

@Pinek w tym przypadku encji nie ma przychodzi model z api zewnetrzengo jest przetwarzany i idzie dalej

Przychodzi model czyli jakaś struktura, schemat, czy json, obiektu odpowiedniego do modelu?

no Model jako model danych/json, który bedzie przetwarzany, ale nie jest zapisywany do encji żadnej, nie jest persystowany i nie ma potrzeby tez walidacji bo to słowniki itp, więc jako tako: zew.api -> dto1 -> model -> dto2 -> front imho nie ma sensu robić, robię tak zew.api-> model -> dto1 -> front

Mhm, czyli zanim przyjdzie ten json, to nie wiesz jakie będzie miał pola tak?

To nie jest w ogóle tu problemem. Pytanie dotyczy tego czy układając strukturę danych lepiej robić wewnętrzen klasy czy deklarowac je za zewnatrz głównego pojo przyjmującego/wysyłającego jsona

No to ogólnie rzecz biorąc, wewnętrzne klasy są słabe. I akceptowalne tylko w bibliotekach i frameworkach :P