Benennungskonvention für Java-Datenübertragungsobjekte?

Question

Wie können Sie angesichts dieses Szenarios, in dem Sie „Übertragungsobjekte“ (POJOs mit nur Gettern/Settern) haben, die von einer Clientbibliothek an Ihre API übergeben werden, die Übertragungsobjekte am besten benennen?

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 diesem Beispiel haben Ihre Hauptklasse und Ihr Transferobjekt beide den Namen Car.Sie sind in verschiedenen Paketen erhältlich, aber ich finde es verwirrend, den gleichen Namen zu haben.Gibt es eine Best Practice für die Benennung der Übertragungsobjekte?

Answer 1

Ich füge im Allgemeinen 'DTO' zum Ende des Klassennamens hinzu und platziere alle DTOs in ihrem eigenen Paket. In Ihrem Beispiel würde ich es com.x.core.dto.cardto nennen.

Answer 2

Dan einer Tübertragen ÖObjekt Der Unterricht sollte dem folgen Namenskonvention definiert in der Java-Sprachspezifikation:

Namen von Klassentypen sollten beschreibende Substantive oder Nominalphrasen sein, nicht zu lang, in gemischter Groß- und Kleinschreibung, wobei der erste Buchstabe jedes Wortes groß geschrieben werden sollte.

ClassLoader
SecurityManager
Thread
Dictionary
BufferedInputStream

[...]

---

Anhängen eines Klassennamens mit DTO oder Dto ist nicht wirklich aussagekräftig und sagt nicht viel über die Klasse selbst aus.Erwägen Sie die Verwendung von Namen, die das beschreiben Zweck Ihrer Klassen.

Hier ist eine nicht erschöpfende Liste von Namensvorschlägen, die Sie verwenden könnten:

• Eine Art vonBefehl
• Eine Art vonAufbau
• Eine Art vonReferenzen
• Eine Art vonEinzelheiten
• Eine Art vonElement
• Eine Art vonEreignis
• Eine Art vonHeader
• Eine Art vonEingang
• Eine Art vonAnweisung
• Eine Art vonArtikel
• Eine Art vonNachricht
• Eine Art vonMetadaten
• Eine Art vonBetrieb
• Eine Art vonAusgabe
• Eine Art vonNutzlast
• Eine Art vonProjektion
• Eine Art vonAbfrageparameter
• Eine Art vonAbfrageergebnis
• Eine Art vonDarstellung
• Eine Art vonAnfrage
• Eine Art vonRessource
• Eine Art vonAntwort
• Eine Art vonErgebnis
• Eine Art vonReihe
• Eine Art vonEinstellungen
• Eine Art vonSpezifikation
• Eine Art vonStatus
• Eine Art vonZusammenfassung

---

^{Anmerkung 1: Ob Akronyme oder alle großgeschriebenen Wörter als Wörter behandelt werden sollen oder nicht, liegt wohl bei Ihnen.Überprüf den Java-API und Sie werden einige Stolpersteine ​​finden ZipInputStream / GZIPInputStream.Beide Klassen sind in der gleiches Paket und die Namenskonvention ist nicht konsistent. HttpURLConnection zeigt auch keine Konsistenz mit Akronymen.}

^{Anmerkung 2: Einige der oben aufgeführten Namen wurden davon entlehnt Artikel geschrieben von Richard Dingwall (Der Originalartikel scheint nicht mehr verfügbar zu sein, also Hier ist eine zwischengespeicherte Kopie aus dem Webarchiv).}

Answer 3

Das Hinzufügen von DTO oder DAO oder irgendetwas anderes verstößt gegen Trocken. Der FQN ist vollkommen in Ordnung, besonders wenn sie wirklich dasselbe sind.

Answer 4

Ich glaube nicht, dass es eine Best Practice oder Convention für eine Klasse gibt, die diese Art von Verhalten ausstellt. Ich persönlich mag das Wortobjekt in keinem der Klassennamen. Sie können entweder eine Qualifikation wie poko.car verwenden oder eine Namenskonvention wie CAR (für Pojo) Carda (für Datenzugriff) Carbiz (für Geschäftsdomänenklassen) verwenden.

Oder wenn es Ihnen nichts ausmacht, das Wort Objekt in einem Klassennamen zu machen, gehen Sie für etwas wie Cardo (CAR -Datenübertragungsobjekt)

Answer 5

Verwenden Sie eine Konvention, die zu den anderen von Ihnen verwendeten Codekonventionen geeignet ist. Ich persönlich verwende das Suffix "to" (z. B. das Datenübertragungsobjekt, das der Kundendomänenklasse zugeordnet ist, benannt Customerto). Auch die Paketstruktur sollte die Absicht jeder Art von Klasse vermitteln (So.foo.domain.customer und so.foo.transport.customerto)