Соглашение об именовании объектов передачи данных Java?

учитывая этот сценарий, где у вас есть "объекты передачи" (POJO'S с только геттерами/сеттерами), которые передаются клиентской библиотекой в ваш API, каков наилучший способ назвать объекты передачи?

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

в этом примере Ваш основной класс и объект передачи имеют имя Car. Они находятся в разных пакетах, но я думаю, что это запутанно иметь одно и то же имя. Есть ли наилучшая практика в том, как назвать объекты передачи?

26
data-transfer-objects java naming-conventions

5 ответов

Я обычно добавляю " DTO " в конец имени класса, а также помещаю все DTO в свой собственный пакет. В вашем примере я бы назвал это ком.х.ядро.dto.Карточки.

25

Data Tтрансфер Object классы должны следовать конвенция имя определена в Спецификация Языка Java:

имена типов классов должны быть описательными существительными или существительными фразами, не слишком длинными, в смешанном случае с первой буквой каждого слова с заглавной буквы.

ClassLoader
SecurityManager
Thread
Dictionary
BufferedInputStream

[...]

суффикс имени класса с DTO или Dto на самом деле не имеет смысла и не говорит много о самом классе. Рассмотрите возможность использования имен, описывающих цель из ваших классов.

вот неисчерпывающий список предложений имен, которые вы могли бы 1: должны ли аббревиатуры или все заглавные слова обрабатываться как слова или нет, я думаю, это зависит от вас. Проверьте Java API и вы найдете некоторые запинают как ZipInputStream / GZIPInputStream. Оба класса находятся в тот же пакет и соглашение об имени не согласуется. HttpURLConnection также не показывает никакой согласованности с аббревиатурами.

примечание 2: некоторые имена перечисленные выше, были заимствованы из этой статьи написано Ричард Дингуолл (оригинальная статья, похоже, больше не доступна, поэтому вот кэшированная копия из веб-архива).

82

добавление DTO или DAO или что-либо еще нарушает сухой. FQN в полном порядке, особенно если они действительно одно и то же.

5

Я не думаю, что есть лучшая практика или Соглашение для класса, демонстрирующего такое поведение. Мне лично не нравится слово Object в любом из имен классов. Вы могли бы использовать некоторую квалификацию, такую как Poko.Автомобиль или использовать некоторые соглашения об именах, такие как Автомобиля (для POJO-объект) CarDa (для доступа к данным) CarBiz (для класса бизнес-домена)

или если вы не возражаете против объекта слово в имени класса пойти на что-то вроде карточки (автомобиль объект передачи данных)

2

используйте соглашение, которое подходит среди других соглашений кода, которые вы используете. Я лично использую суффикс " TO " (например, объект передачи данных, связанный с классом домена клиента, называется CustomerTO). Кроме того, структура пакета должна передавать намерение каждого типа класса (so.foo.домен.Клиент и так далее.foo.транспорт.CustomerTO)

-1