Convenzione di denominazione dell'oggetto di trasferimento dati Java?

Question

Dato questo scenario in cui hai "oggetti di trasferimento" (Pojo's with Just Getters/Setter) che vengono passati da una libreria client alla tua API, qual è il modo migliore per nominare gli oggetti di trasferimento?

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

In questo esempio la tua classe principale e l'oggetto di trasferimento hanno entrambi il nome Car. Sono in pacchetti diversi ma penso che sia confuso avere lo stesso nome. Esiste una migliore pratica su come nominare gli oggetti di trasferimento?

Answer 1

In genere aggiungo "dto" alla fine del nome della classe e metto tutti i DTO nel loro pacchetto. Nel tuo esempio lo chiamerei com.x.core.dto.cardto.

Answer 2

Data TRansfer Object Le lezioni dovrebbero seguire il Nome Convention definito nel Specifica del linguaggio Java:

I nomi dei tipi di classe dovrebbero essere nomi descrittivi o frasi di sostantivo, non troppo lunghi, in caso misto con la prima lettera di ogni parola capitalizzata.

ClassLoader
SecurityManager
Thread
Dictionary
BufferedInputStream

[...]

---

Suffisso con un nome di classe con Dto o Dto non è davvero significativo e non parla molto della classe stessa. Considera l'uso di nomi che descrivono il scopo delle tue lezioni.

Ecco un elenco non esaustivo di suggerimenti di nome che potresti usare:

• Una specie diComando
• Una specie diConfigurazione
• Una specie diCredenziali
• Una specie diParticolari
• Una specie diElemento
• Una specie diEvento
• Una specie diIntestazione
• Una specie diIngresso
• Una specie diIstruzione
• Una specie diElemento
• Una specie diMessaggio
• Una specie diMetadati
• Una specie diOperazione
• Una specie diProduzione
• Una specie diCarico utile
• Una specie diProiezione
• Una specie diQueryparameter
• Una specie diQueryResult
• Una specie diRappresentazione
• Una specie diRichiesta
• Una specie diRisorsa
• Una specie diRisposta
• Una specie diRisultato
• Una specie diRiga
• Una specie diImpostazioni
• Una specie diSpecifica
• Una specie diStato
• Una specie diRiepilogo

---

^{Nota 1: Sia che gli acronimi o tutte le parole capitalizzate debbano essere gestite come parole o no, immagino dipenda da te. Controlla il API Java E troverai alcuni inciampi come ZipInputStream / GZIPInputStream. Entrambe le classi sono nel Stesso pacchetto E il nome Convenzione non è coerente. HttpURLConnection Non mostra nemmeno coerenza con gli acronimi.}

^{Nota 2: Alcuni nomi sopra elencati sono stati presi in prestito da questo articolo scritto da Richard Dingwall (L'articolo originale sembra non essere più disponibile, quindi Ecco una copia memorizzata nella cache dall'archivio web).}

Answer 3

L'aggiunta di DTO o DAO o qualsiasi altra cosa viola. L'FQN va benissimo, soprattutto se sono davvero la stessa cosa.

Answer 4

Non credo che ci sia una migliore pratica o una convenzione per una classe che esibisce questo tipo di comportamento. Personalmente non mi piace la parola oggetto in nessuno dei nomi di classe. È possibile utilizzare alcune qualifiche come Poko.Car o utilizzare alcune convenzioni di denominazione come Car (per Pojo) cardacano (per accesso ai dati) Carbiz (per la classe di dominio aziendale)

O se non ti dispiace la parola oggetto in un nome di classe, vai per qualcosa come Cardto (Oggetto di trasferimento dei dati automobilistici)

Answer 5

Usa una convenzione adatta tra le altre convenzioni di codice che stai utilizzando. Uso personalmente il suffisso "a" (ad esempio l'oggetto di trasferimento dati associato alla classe di dominio del cliente è denominato Customerto). Anche la struttura del pacchetto dovrebbe trasmettere l'intento di ogni tipo di classe (So.foo.domain.customer e So.foo.transport.customert)