[JAVA] Avez-vous arrêté de penser à utiliser getter / setter dans le modèle de conception DTO?

Lors de l'implémentation d'un modèle de conception DTO en Java, vous ajoutez setter / getter Je me demande si j'ai arrêté de penser.

• Citation DTO Wikipedia L'objet de transfert de données (DTO) est un type de modèle de conception utilisé pour transférer des données entre des sous-systèmes dans un logiciel d'application.

Cela ressemble à une implémentation.

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

Compte tenu de l'objectif, je pense qu'il ne devrait pas inclure de logique. Ensuite, l'implémentation n'aura que des getters / setters pour les champs. L'encapsulation ne fonctionne pas du tout, c'est donc rafraîchissant ce que vous voulez faire.

• Je peux comprendre l'histoire d'être mal à l'aise à cause de l'unité de l'ensemble.

La mise en œuvre qui rend le champ public est donc simple. Pratique pour compléter de l'IDE!

class Hoge
{
    public int value;
}

Ensuite, comme facteur à pousser ensuite, ce n'est pas un bean Java On vous le dira peut-être.

Cependant, compte tenu de l'objectif du DTO, il ne devrait pas être nécessaire de devenir un haricot. Pourquoi voulez-vous en faire un haricot? Si vous pensez

Je ne peux pas utiliser "BeanUtils.copyProperties"! Peut être dit. Mais n'est-ce pas mal comprendre le but et les moyens? Je pense. Il aurait dû être établi en tant que DTO.

Alors pourquoi voudriez-vous utiliser "BeanUtils.copyProperties"? Je pense que ce sera.

la prochaine fois Avez-vous arrêté de penser à utiliser BeanUtils.copyProperties?

Si vous avez des opinions ou des impressions, veuillez nous en informer.