Convention de dénomination des objets de transfert de données Java?

StackOverflow https://stackoverflow.com/questions/1724774

Question

Compte tenu de ce scénario où vous avez des "objets de transfert" (Pojo avec Just Getters / Setters) qui sont passés par une bibliothèque client à votre API, quelle est la meilleure façon de nommer les objets de transfert?

package com.x.core; 

public class Car {
        private String make;
        private String model;

        public Car(com.x.clientapi.Car car) {
             this.make = car.getMake();
             this.model = car.getModel();
        }
}

Dans cet exemple, votre classe principale et votre objet de transfert ont tous deux le nom Car. Ils sont dans différents packages, mais je pense que c'est déroutant d'avoir le même nom. Existe-t-il une meilleure pratique sur la façon de nommer les objets de transfert?

Était-ce utile?

La solution

J'ajoute généralement le «DTO» à la fin du nom de classe et je place tous les DTO dans leur propre package. Dans votre exemple, je l'appellerais com.x.core.dto.cardto.

Autres conseils

réà Transférer Ofaire un coup de fouet Les classes doivent suivre le congrès de noms défini dans le Spécification de la langue Java:

Les noms des types de classes doivent être des noms descriptifs ou des phrases nominales, pas trop longs, dans un cas mixte avec la première lettre de chaque mot capitalisé.

ClassLoader
SecurityManager
Thread
Dictionary
BufferedInputStream

[...]

Suffixer un nom de classe avec DTO ou DTO n'est pas vraiment significatif et ne dit pas grand-chose sur la classe elle-même. Envisagez d'utiliser des noms qui décrivent le objectif de vos cours.

Voici une liste non exhaustive des suggestions de noms que vous pourriez utiliser:

  • Un genre deCommande
  • Un genre deConfiguration
  • Un genre deIdentifiants
  • Un genre deDétails
  • Un genre deÉlément
  • Un genre deÉvénement
  • Un genre deEntête
  • Un genre deSaisir
  • Un genre deInstruction
  • Un genre deArticle
  • Un genre deMessage
  • Un genre deMétadonnées
  • Un genre deOpération
  • Un genre deProduction
  • Un genre deCharge utile
  • Un genre deProjection
  • Un genre deQuéryparamètre
  • Un genre deRequête
  • Un genre deReprésentation
  • Un genre deDemande
  • Un genre deRessource
  • Un genre deRéponse
  • Un genre deRésultat
  • Un genre deLigne
  • Un genre deRéglages
  • Un genre despécification
  • Un genre deStatut
  • Un genre deSommaire

Note 1: Que les acronymes ou tous les mots capitalisés soient gérés comme des mots ou non, je suppose que c'est à vous. Vérifier la API Java Et vous trouverez des trébuchements comme ZipInputStream / GZIPInputStream. Les deux classes sont dans le même paquet Et la convention de nom n'est pas cohérente. HttpURLConnection ne montre aucune cohérence avec les acronymes non plus.

Note 2: Certains noms énumérés ci-dessus ont été empruntés à ce article écrit par Richard Dingwall (L'article original semble ne plus être disponible, donc Voici une copie en cache des archives Web).

L'ajout de DTO ou DAO ou toute autre chose viole le sec. Le FQN est parfaitement bien, surtout s'ils sont vraiment la même chose.

Je ne pense pas qu'il y ait une meilleure pratique ou une convention pour un cours présentant ce type de comportement. Personnellement, je n'aime pas l'objet Word dans aucun des noms de classe. Vous pouvez soit utiliser des qualifications comme Poko.car, soit utiliser une convention de dénomination comme la voiture (pour Pojo) Carda (pour l'accès aux données) Carbiz (pour la classe de domaine commercial)

Ou si cela ne vous dérange pas l'objet Word dans un nom de classe, optez pour quelque chose comme CardTo (Car Data Transfer Object)

Utilisez une convention qui convient parmi les autres conventions de code que vous utilisez. J'utilise personnellement le suffixe "pour" (par exemple, l'objet de transfert de données associé à la classe de domaine client est nommé personnalisé). La structure du package doit également transmettre l'intention de chaque type de classe (so.foo.domain.customer et so.foo.transport.costomerto)

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top