2016-10-28 1 views
0
@JsonRootName(value = "studentInfo") 
@JsonInclude(value = Include.NON_EMPTY) 
public class StudentInfo { 
    private String student; 
    @JsonProperty("address") 
    private String address; 

    @JsonProperty("studentName") 
    public String getStudent() { 
     return student; 
    } 

    @JsonProperty("studentUserId") 
    public void setStudent(String student) { 
     this.student = student; 
    } 
    public String getAddress() { 
     return address; 
    } 

    public void setAddress(String address) { 
     this.address = address; 
    } 
} 

Voici ma classe Student J'utilise cet objet dans mon API liée à l'étudiant comme DTO. Ici, j'ai utilisé la variable Student String de telle sorte que lorsque POST/PUT/ API est appelée et que studentUserId est passé, elle sera définie sur la variable Student String mais chaque fois que l'objet StudentInfo est renvoyé comme entité de réponse, il renverra le nom réel de Student qui est stocké dans la table utilisateur. Je veux juste savoir que, la façon dont j'ai utilisé la variable élève String et @JsonProperty pour cela, est la bonne façon d'utiliser ou sa mauvaise pratique?Est-il une mauvaise pratique d'utiliser une même variable pour deux but dans DTO

+5

Oui, c'est une mauvaise pratique. Vous devriez avoir un champ séparé 'userId' dans votre classe. En utilisant le même champ pour des données différentes, il y a juste des bugs qui peuvent arriver. Il sera également très déroutant lorsque d'autres personnes regarderont la classe plus tard. – marstran

+1

C'est aussi un cauchemar d'écrire des tests pour cette classe si la sémantique d'un champ dépend du contexte dans lequel il est utilisé. – Fildor

Répondre

4

Non seulement une règle pour un DTO, mais pour toutes les classes, les programmes et les langues (essentiellement dans la vie réelle non académique), lors de la programmation, chaque variable et l'attribut a son propre but et utilisé uniquement pour ce.

Si vous suivez cette règle, vous suivrez aussi les conventions sur:

  • Nommer (chaque variable aura un decriptive et nom unique)
  • Lisibilité (non seulement vous, aussi d'autres seront voir et savoir comment chaque variable est utilisée)
  • Maintanability (lorsque quelque chose change -et oui, il Change-, vous aurez pas besoin de diviser ou faire des solutions de contournement de Uglies pour faire modifier ou corriger le problème)
  • testabilité est un cauchemar pour écrire des tests pour la classe si la sémantique d'un champ dépend le contexte dans lequel il est utilisé. (@Fildor)

Et quelques autres. Quoi qu'il en soit, ce ne sont que des conventions et non des règles obligatoires, la syntaxe sera confuse mais correcte, vous pouvez donc l'utiliser. Ma recommandation est: pas!;)

+0

J'aimerais ajouter de la testabilité à cette liste. – Fildor

+0

@Fildor ajouté ... merci! –

+1

Vous avez raison. Pas impossible, mais très laid et compliqué. Étant donné le scénario dans la question: je devrais écrire le test afin qu'il prenne en compte le contexte (utilisé comme réponse/utilisé comme requête). Bien sûr, on pourrait argumenter que ce champ n'est testé que pour ce qu'il contient la valeur réelle que je lui donne, mais il peut y avoir plus. Je parle donc de façon générale. Un meilleur exemple serait un champ numérique avec des limites. Basé sur le contexte, il peut avoir différentes limites valides qui ont dû être testées en tenant compte du contexte. Fait pour un test instable laide ... au moins à mon humble avis. – Fildor