[JAVA] [Spring] Pièges de BeanUtils.copyProperties

BeanUtils.copyProperties [BeanUtils.copyProperties] pour Spring (https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/beans/BeanUtils.html#copyProperties-java.lang.Object-java Il existe une méthode pratique appelée .lang.Object-). C'est une méthode qui copie le contenu d'un champ avec le même nom d'un bean à l'autre. Le premier argument est la source de la copie et le deuxième argument est la destination de la copie. Même si les classes sont différentes, la copie est possible si elles ont le même nom de champ.

** Cours Livre **

public class Book {

    String code;

    String name;

    int price;
}

** Exemple d'utilisation **

Book book1 = new Book();

book1.setCode("A");
book1.setName("Trois Royaumes");
book1.setPrice(500);

Book book2 = new Book();

BeanUtils.copyProperties(book1, book2);

En faisant cela, les valeurs «code», «name» et «price» de «book1» sont copiées dans «book2» dans leur intégralité.

Piège 1: mourir si le nom du champ change lors de la copie vers un objet d'une classe différente

Par exemple, supposons que vous ayez le formulaire et Dto suivants.

Classe ** CreateBookForm **

public class CreateBookForm {

    String code;

    String name;

    int price;
}

** Classe BookDto **

public class BookDto {

    String code;

    String name;

    int price;

    String updateModule;

}

Écrire innocemment BeanUtils.copyProperties (createBookForm, bookDto) dans le mappage Form-> Dto augmentera le taux de mortalité.

Supposons que le nom de champ de «CreateBookForm» passe de «code» à «cd» en raison de la commodité du frontal.

Classe ** CreateBookForm ** (après modification)

public class CreateBookForm {

    String cd;

    String name;

    int price;
}

Cela ne copiera plus cd-> code. C'est parce que les noms de champ sont différents. Ensuite, vous devez changer le nom de champ de BookDto! Il peut y avoir une opinion, mais ce n'est pas cool que les changements se touchent dans la classe préparée pour la séparation des couches.

Lorsque vous utilisez cette méthode, je pense que les principes suivants doivent être respectés.

• Ne copiez pas d'objets de classes différentes! Il n'y a aucune garantie que le nom du champ ne changera pas pour toujours! Cependant, les classes avec des relations d'héritage sont exclues.
• Si vous avez vraiment besoin de copier des objets de différentes classes, écrivez un test unitaire pour vous assurer qu'ils sont copiés!

Piège 2: Une méthode avec le même nom et le même nom existe dans une autre bibliothèque

Cette méthode, avec exactement le même nom, est la [Apache Commons Library](https://commons.apache.org/proper/commons-beanutils/apidocs/org/apache/commons/beanutils/BeanUtils.html#copyProperties-java.lang Il existe dans .Object-java.lang.Object-). De plus, cette méthode, ** le deuxième argument est la source de la copie et le premier argument est la destination de la copie **. L'ordre des arguments est inversé par rapport à celui de Spring du même nom! !! Notez que lors de l'utilisation de l'importation automatique de bibliothèques dans l'EDI, certaines classes peuvent appeler Spring et certaines classes peuvent appeler les copyProperties d'Apache, ce qui peut être inaperçu et créer une dépendance. J'en étais accro.

Personnellement, j'ai une forte impression de "de gauche à droite = du premier argument au deuxième argument" dans "copier la source-> copier la destination", donc j'utilise toujours celui de Spring.