[JAVA] Haben Sie aufgehört, über die Verwendung von BeanUtils.copyProperties nachzudenken?

Javas "BeanUtils.copyProperties" ist eine sehr nützliche Funktion Wird es wirklich richtig benutzt?

Dieses Mal möchte ich über Entitäts-, DTO- und Formularmuster sprechen.

• Obwohl es sich nur um ein Entwurfsmuster für DTO handelt, scheint es seltsam, diesen Namen zu nennen ...

Siehe den Fall, in dem Entität, DTO und Formular als Beans implementiert sind. Aber ist das nicht der Grund, nur "BeanUtils.copyProperties" verwenden zu wollen?

Zum Beispiel diese Implementierung

class EntityBean
{
    private int value;
    public int getValue(){ return value; }
    public void setValue(int value){ this.value = value; }
}

class DtoBean
{
    private int value;
    public int getValue(){ return value; }
    public void setValue(int value){ this.value = value; }
}

class FormBean
{
    private int value;
    public int getValue(){ return value; }
    public void setValue(int value){ this.value = value; }
}

Wenn Sie dasselbe Feld in Entität, DTO, Formular, "BeanUtils.copyProperties" haben Ich denke, es ist sicherlich möglich und bequem zu bedienen.

Aber überlegen Sie es sich zweimal. Ist Entity, DTO, Form nicht dazu gedacht, unterschiedliche Implementierungen aufzunehmen?

Dasselbe Feld haben, weil Sie "BeanUtils.copyProperties" verwenden möchten Ist es nicht gezwungen? In diesem Fall ist es nicht resistent gegen Änderungen, und die Spezifikationen der Datenbank werden geändert. Sie müssen die Entität, das DTO und das Formular weiterhin manuell bedienen.

Wenn der Feldname aufgrund der Änderung der DB-Spezifikation geändert wird

Geändert zu Entity value-> hoge.

class EntityBean
{
    private int hoge;
    public int getHoge(){ return hoge; }
    public void setHoge(int hoge){ this.hoge = hoge; }
}

class DtoBean
{
    private int value;
    public int getValue(){ return value; }
    public void setValue(int value){ this.value = value; }
}

class FormBean
{
    private int value;
    public int getValue(){ return value; }
    public void setValue(int value){ this.value = value; }
}

Dies wird den Build bestehen, solange Sie "BeanUtils.copyProperties" verwenden. Es besteht die Möglichkeit, dass es sich so bewegt, wie es ist. An die Person, die das DTO und das Formular erstellt (vielleicht an mich selbst) Sie müssen kommunizieren und korrigieren lassen. Sie benötigen außerdem Testcode, damit er funktioniert.

Wo lohnt es sich, diese Kosten zu bezahlen? Gibt es einen Montagefehler?

Wenn Sie das gleiche Feld an drei Stellen erzwingen können (können), Entität, DTO, Formular Vererbung ist eine gute Implementierung.

class EntityBean
{
    private int hoge;
    public int getHoge(){ return hoge; }
    public void setHoge(int hoge){ this.hoge = hoge; }
}

class DtoBean extends EntityBean
{
}

class FormBean extends DtoBean
{
}

Sie können sicher sein, dass Sie dieselben Felder haben und auf Codeebene, wenn Änderungen vorgenommen werden Beachten Sie Fehler bei der Erstellung, wenn sie sich ändern.

Da es vererbt ist, können Sie die Eigenschaft, wenn Sie sie entfernen möchten, upcasten und es wird möglich sein "BeanUtils.copyProperties" muss überhaupt nicht verwendet werden.

Aber hat nicht das gleiche Feld an drei Stellen, Entität, DTO und Form, den Zweck an erster Stelle zunichte gemacht?

Das möchte ich wirklich tun.

class EntityBean
{
    //Entität hat ein Datum als Datumstyp
    private DateTime date;
    public DateTime getDate(){ return date; }
    public void setDate(DateTime date){ this.date = date; }
}

class DtoBean
{
    //DTO hat ein Datum als Zeichenfolgentyp
    private String date;
    public String getDate(){ return date; }
    public void String(String date){ this.date = date; }
}

class FormBean
{
    //Formular hat Datum nach Datum
    private String year;
    private String month;
    private String day;
}

Weil "Entität, DTO, Formular" unterschiedliche Implementierungen haben kann Es ist eine Unterteilung, und es macht keinen Sinn, wenn dieselbe Implementierung angenommen wird. Solange Sie "BeanUtils.copyProperties" verwenden, ist die Abstraktion gering und unvorbereitet.

Wer sollte in erster Linie für die Konvertierung zwischen "Entität" und "Formular" verantwortlich sein? Zögern Sie, mit "BeanUtils.copyProperties" Verantwortung zu übernehmen?

Übrigens, wer hat im obigen Beispiel die Rolle des "DTO"? Ich denke nicht, dass es notwendig ist. DTO wird nur benötigt, wenn es mit mehreren Entitäten verknüpft ist.

Sie brauchen wirklich eine andere Person, um die Rolle der Konvertierung von "Entität" und "Form" zu spielen.

class EntityBean
{
    //Entität hat ein Datum als Datumstyp
    private DateTime date;
    public DateTime getDate(){ return date; }
    public void setDate(DateTime date){ this.date = date; }
}

class Converter
{
   //Dieser Typ ist dafür verantwortlich, Methoden für die Konvertierung vorzubereiten
   public static EntityBean convert(FormBean form) ...Die Implementierung entfällt
   public static FormBean convert(EntityBean form) ...Die Implementierung entfällt
}

class FormBean
{
    //Formular hat Datum nach Datum
    private String year;
    private String month;
    private String day;
}

Wenn Sie "BeanUtils.copyProperties" in "Converter" verwenden Ich denke, der Abstraktionsgrad bleibt erhalten.

Erstellen Sie manuell dieselben Felder an drei Stellen: Entität, DTO, Formular Es verwendet "BeanUtils.copyProperties" als Entwurfsvoraussetzung. Gibt es keinen Fall um dich herum?

Ist das wirklich richtig? Ich frage mich. Wir freuen uns von Ihnen zu hören.