@otsochodzi A po co w ogóle dane kontaktowe osobno? Potrzebujesz one-to-many?

2 i 3 są nie reliable i mogą być manipulowane. Ja bym robił post na całości jako user, a zmiany jeśli potrzebne pchał w contact, dzięki temu masz relacje 1 do 1 i działanie frontendu/internetu nie jest potrzebne do spójności danych

@Voltage ponieważ chce aby ktoś mógł je wprowadzić podczas dodawania użytkownika ale jeśli nie to może zrobić to później

@otsochodzi Mam wrażenie, że niepotrzebnie komplikujesz sprawę. Oddzielne DTO dla kontaktu ma jakiś konkretny cel? Jeżeli nie to zawarłbym to jako część usera. Dla FE lepiej jeden endpoint na tworzenie usera z danymi kontaktowymi i drugi na aktualizację tych danych. Ale nawet jeżeli byś chciał oddzielne DTO, to i tak zrobiłbym jeden endpoint dla FE a na backendzie zrobił transakcję na tworzenie obu naraz.

@otsochodzi a jak wygląda JSON?

@otsochodzi

ponieważ chce aby ktoś mógł je wprowadzić podczas dodawania użytkownika ale jeśli nie to może zrobić to później

No, na tym polega edycja usera, chyba że masz specjalny powód żeby wyodrębnić ten kontakt do innego modelu/formularza, to wtedy można kombinować nad lepszym rozwiązaniem, ale KISS i YAGNI

@Voltage czyli zrobiłbyś jedno DTO dla informacji o użytkowniku i kontakcie, a następnie umożliwił edycję, dobrze rozumiem?

@otsochodzi nie dałeś zbyt dokładnego opisu, więc przyjmuję że user będzie miał jedne dane kontaktowe, to raptem kilka pól w bazie więc tak, zrobiłbym UserDto z polami kontaktowymi, jak ktoś chce później dodać te dane to sobie edytuje. Zresztą to nie jest coś co trudno zmienić na dalszym etapie gdy np. potrzeba biznesowa rozdzielenia logiki faktycznie nastąpi.

@Voltage czy DTO powinny w ogóle zawierać relacje do innych obiektów czy raczej wszystkie potrzebne dane powinny być w jednej klasie?. Pytam ogólnie ponieważ DTO powinno być lekkie więc umieszczanie tam relacji do obiektów z kolejnymi polami trochę łamie tę zasadę

@otsochodzi Relacje powinieneś tworzyć w odpowiedniej warstwie, DTO najlepiej jak jest po prostu płaskie i zawiera dane które przenosisz między warstwami aplikacji. Najlepiej jak jest ich jak najmniej, wtedy nie musisz mieć od groma mapowań, więc jak chcesz zamieszczać kolejne klasy w DTO (jak np. wymieniłeś w pkt 1) to już trochę kłóci się z ideą DTO, przynajmniej tą purystyczną.

@otsochodzi IMO to trochę zależy od przypadku.

Jak masz prosty obiekt np. userName, password, email, phoneNumber, language - to nie ma sensu nic wydzielać. Ale jakbyś miał sporo pól, które można pogrupować i wydzielić, to ja bym już wydzielił, np.

userName,

password,

contanct: email, phoneNumber,

permanentResidenceAddress: country, city, streetName, streetNumber,

residenceAddress: country, city, streetName, streetNumber,

preferences: theme, language, timeZone

Ale to ja bym tak zrobił, może być to błędne myślenie i zaraz ktoś mnie wyjaśni ¯\_(ツ)_/¯

@otsochodzi 3. Nie rób tego, próba polegania na zrobieniu transakcji przez front jest fajna na localhoscie, później już nie

2. To po prostu przeniesienie logiki z backendu na frontend, ja generalnie wolę jak to backend jest 'mądrzejszy', wtedy po prostu można pisać mniej jsa i mniej pchać do userów
   

1. Jeden dto, używaj optionali, na podstawie tego dto możesz mieć 2 osobne metody w serwisie na 'czystego' usera albo nie, ale ta logikę możesz ładnie zenkapsulować już w kodzie aplikacji, natomiast wiadomo że tworzenie będzie postem, a update jeżeli całości to put, a tylko części to patch
   

Dla mnie DTO (jeżeli mówimy o takim serializowanym do jsona i używanym przez UI) powinno działać jak backend for frontend, czyli zawierać to co klient oczekuje w danym miejscu, bez dociągania requestami, np. jeżeli usera zawsze wyswietlasz z danymi do kontaktu, wpakuj razem, jeżeli dane to odrębny byt który czasem pokazujesz, a czasem nie, to osobno

Premature optimization is the root of all evil, dopóki nie wrzucasz kilku relacji z listami po setki obiektów, będzie dobrze

@HmmJakiWybracNick @bzyku95 ale przecież na stronach, np. e commerce można spotkać formularze, która składają się z wielu danych, która są wysyłane w jednym DTO, być może jest ono posegregowane odpowiednio na osobne klasy ale wtedy i tak trzeba zadecydować, który kontroler ma te dane zapisać, który jest nadrzędny, prawda?

@otsochodzi Ja bym robił jak napisałeś, czyli wysyłasz to jednym dto, który w Twoim przypadku nazwałbym np. UserCreateData i który byłby albo płaską struktura, albo jak tych pól jest np. 60 (XD) to kompozycją. Przyjmowałby to jakiś UserController, który pchałby to do jakiejś fasady czy serwisu, który znowu używając jakiegoś mappera/konwertera robiłby z tego entity (o ile celem jest zapisanie tego do db), żeby zapisać do odpowiednich tabelek - oczywiście pamiętając o ogarnięciu tego w transakcji. Jak tych danych jest dużo, to może warto na frontendzie rozważyć zrobienie jakiegoś wizarda, żeby podzielić to na mniejsze kroki.