Sollte ich Builder-Muster in DTO verwenden?
Dies mag eine ziemlich subjektive Frage sein, aber ich würde gerne mehr Meinungen erfahren. Ich habe einen Rest API-Dienst mit Spring MVC erstellt und das DTO-Domain-Entity-Muster implementiert. Ich möchte wissen, was Sie über die Implementierung des @ denkBuilder pattern in DTOs, so etwas wie
public class UserResponseDTO
extends AbstractResponseDTO {
private String username;
private Boolean enabled;
public UserResponseDTO(String username, Boolean enabled) {
this.username = username;
this.enabled = enabled;
}
public String getUsername() {
return this.username;
}
public Boolean getEnabled() {
return this.enabled;
}
public static class Builder {
private String username;
private Boolean enabled;
public void setUsername(String username) {
this.username = username;
}
public void setEnabled(Boolean enabled) {
this.enabled = enabled;
}
public UserResponseDTO build(){
return new UserResponseDTO(username, enabled);
}
}
}
Nach der Definition:
Die Absicht des Builder-Entwurfsmusters besteht darin, die Konstruktion eines komplexen Objekts von seiner Darstellung zu trennen. Auf diese Weise kann derselbe Konstruktionsprozess verschiedene Darstellungen erstellen.
In den meisten meiner DTO-Fälle (um nicht alle von ihnen zu sagen) habe ich kein komplexeres Objekt zu bauen, wie in diesem Fall. Und ehrlich gesagt, ich kann mir kein Beispiel vorstellen, in dem ein komplexes Objekt erstellt wird, wenn wir über DTOs sprechen.
Eines der Muster, das die Verwendung unveränderlicher Objekte erleichtert und dem Code mehr Klarheit verleiht, ist das Builder-Muster.
Builder-Muster bietet Objekte Unveränderlichkeit. Dann können wir denken, dass ein DTOs die Service-Antwort selbst ist und nicht geändert werden sollte, da dies eine Antwort ist (zumindest denke ich so darüber nach)
Also was denkst du? Soll ich dieses Muster für DTOs verwenden (angesichts der Tatsache, dass dieser Fall und wahrscheinlich die meisten von ihnen das komplexe Objektprinzip nicht erfüllen)?