[JAVA] Avez-vous arrêté de penser à utiliser BeanUtils.copyProperties?

"BeanUtils.copyProperties" de Java est une fonctionnalité très utile Est-il vraiment utilisé correctement?

Cette fois, je voudrais parler des modèles Entity, DTO et Form.

• Bien qu'il s'agisse d'un modèle de conception uniquement pour DTO, il semble étrange d'être dit par ce nom ...

Voir le cas où Entity, DTO et Form sont implémentés en tant que beans. Mais n'est-ce pas la raison pour laquelle vous voulez simplement utiliser "BeanUtils.copyProperties"?

Par exemple, cette implémentation

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; }
}

Si vous avez le même champ dans Entity, DTO, Form, "BeanUtils.copyProperties" Je pense que c'est certainement possible et pratique à utiliser.

Mais réfléchissez à deux fois. Entity, DTO, Form ne sont-ils pas censés absorber différentes implémentations?

Avoir le même champ car vous souhaitez utiliser "BeanUtils.copyProperties" N'est-ce pas forcé? Si cela se produit, il ne résistera pas aux modifications et les spécifications de la base de données seront modifiées. Vous devrez continuer à utiliser l'entité, le DTO et le formulaire manuellement.

Lorsque le nom du champ est modifié en raison de la modification de la spécification DB

Changé en valeur d'entité-> 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; }
}

Cela passera la construction tant que vous utilisez "BeanUtils.copyProperties" Il est possible qu'il bouge tel quel. À la personne qui crée le DTO et le formulaire (peut-être moi-même) Vous devez communiquer et le faire corriger. Vous aurez également besoin d'un code de test pour continuer à fonctionner.

Où cela vaut-il la peine de payer ce coût? Y a-t-il une erreur de montage?

Si vous pouvez forcer (pouvez) avoir le même champ à 3 endroits, Entité, DTO, Formulaire L'héritage est une bonne implémentation.

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
{
}

Vous pouvez être assuré que vous avez les mêmes champs, et au niveau du code s'il y a des changements Soyez conscient des erreurs de compilation lorsqu'elles changent.

Puisqu'il est hérité, si vous souhaitez supprimer la propriété, vous pouvez la remonter et ce sera possible Il n'est pas du tout nécessaire d'utiliser "BeanUtils.copyProperties".

Mais le fait d'avoir le même champ à trois endroits, Entity, DTO et Form, ne va-t-il pas à l'encontre de l'objectif en premier lieu?

C'est ce que je veux vraiment faire.

class EntityBean
{
    //L'entité a une date comme type de date
    private DateTime date;
    public DateTime getDate(){ return date; }
    public void setDate(DateTime date){ this.date = date; }
}

class DtoBean
{
    //DTO a une date comme type de chaîne
    private String date;
    public String getDate(){ return date; }
    public void String(String date){ this.date = date; }
}

class FormBean
{
    //Le formulaire comporte des dates par date
    private String year;
    private String month;
    private String day;
}

Parce que "Entity, DTO, Form" peut avoir des implémentations différentes C'est une division, et cela n'a aucun sens si la même implémentation est supposée. Tant que vous utilisez "BeanUtils.copyProperties", il est faible en abstraction et non préparé.

En premier lieu, qui devrait être responsable de la conversion entre «Entité» et «Forme»? Êtes-vous réticent à assumer la responsabilité en utilisant "BeanUtils.copyProperties"?

Au fait, dans le cas de l'exemple ci-dessus, qui a le rôle de "DTO"? Je ne pense pas que ce soit nécessaire. Le DTO n'est pas nécessaire à moins qu'il ne soit lié à plusieurs entités.

Vous avez vraiment besoin d'une autre personne pour jouer le rôle de conversion "Entité" et "Forme".

class EntityBean
{
    //L'entité a une date comme type de date
    private DateTime date;
    public DateTime getDate(){ return date; }
    public void setDate(DateTime date){ this.date = date; }
}

class Converter
{
   //Ce gars est responsable de la préparation des méthodes pour se convertir les uns aux autres
   public static EntityBean convert(FormBean form) ...La mise en œuvre est omise
   public static FormBean convert(EntityBean form) ...La mise en œuvre est omise
}

class FormBean
{
    //Le formulaire comporte des dates par date
    private String year;
    private String month;
    private String day;
}

Si vous utilisez "BeanUtils.copyProperties" dans "Converter" Je pense que le degré d'abstraction est maintenu.

Créez manuellement les mêmes champs à 3 endroits, Entité, DTO, Formulaire Il utilise "BeanUtils.copyProperties" comme prérequis de conception. N'y a-t-il pas un cas autour de vous?

Est-ce vraiment correct? Je me demande. Nous avons hâte d'avoir de tes nouvelles.