Mehr Kontrolle über die „@RequestBody Entity-Entität“ beim Erstellen/Aktualisieren eines Datensatzes ⇐ Java

[Guest]

Ich wechsle von einem anderen Entwicklungsstapel zu Java/Spring und bin sehr verwirrt darüber, wie in Spring einige Dinge erledigt werden.
Eines der Probleme ist die magische Konvertierung von Anforderungskörperparametern in ein Java-Objekt (Entität) mit der Annotation @RequestBody.
Siehe das folgende Beispiel

Code: Select all

@PostMapping
public User create(@RequestBody User user) {}

@PutMapping
public User update(@RequestBody User user) {}

Das Problem besteht darin, dass ich nicht steuern kann, welche Parameter aus einer Anfrage stammen und wie also die Benutzerentität erstellt wird.
Der Benutzer Entität kann viele Felder und Assoziationen haben, z. B.

Code: Select all

    {
"name": "John Doe",
"age": 33,
"email": "[email protected]",
"addresses": [{
"street": "XYZ Main St",
"city": "Test City",
"zip": "12345"
}]
}

Was ist, wenn ich einen Endpunkt zum Erstellen/Aktualisieren haben möchte, der nur Namen und Alter und keine anderen Felder und Zuordnungen festlegen/ändern kann?
Gleichzeitig benötige ich möglicherweise einen anderen Controller für Administratoren, der alle oben gezeigten Benutzer-Felder und -Zuordnungen festlegen/ändern kann.
Wie Kann ich steuern, was in den Anfragetext kommt und wie ein Benutzerdatensatz aussieht? initialisiert?

Ich weiß, dass ich Dinge wie UserDto:
verwenden kann

Code: Select all

public class UserDTO {
private String name;
private Integer age;
}

// Controller
@PostMapping
public User create(@RequestBody UserDto userDto) {}

Aber wie lässt sich dieser Ansatz mit @Valid-bezogenen Annotationen (und anderen) kombinieren, die in der Entitätsklasse definiert sind (

Code: Select all

User

), daher kann ich keine Validierung auf diese Weise durchführen: create(@Valid @RequestBody UserDto userDto).
Oder sollte ich Validierungsregeln sowie Felder definieren? setzt in DTOs?
Und sollte ich DTOs für alle möglichen Endpunkte und Geschäftsfälle erstellen, z. B.

Code: Select all

public class UserDTO {
private String name;
private Integer age;
}

public class AdminUserDTO {
private String name;
private Integer age;
private String email;

private List addresses;
}

Meiner Erfahrung nach wäre es eine gute Lösung, alle Anforderungsparameter „wie sie sind“ zu erhalten (vielleicht als HashMap) und eine neue Entität zu initialisieren (oder eine vorhandene zu ändern). Entität) explizit, um die volle Kontrolle zu haben.
Kann ich explizit eine Liste der zulässigen Parameter angeben?
Gibt es eine Möglichkeit anzugeben, welche Parameter erforderlich und welche optional sind?