Java data transfer object naming convention?

Given this scenario where you have "transfer objects" (POJO's with just getters/setters) which are passed by a client library to your API, what is the best way to name the transfer objects?

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 this example your main class and your transfer object both have the name Car. They are in different packages but I think it's confusing to have the same name. Is there a best practice on how to name the transfer objects?

78149 次浏览
小开
最佳答案

I generally add 'DTO' to the end of the Class name as well as place all the DTO's in their own package. In your example I would call it com.x.core.dto.CarDTO.

小开

I dont think there is a best practice or convention for a class exhibiting this kind of behavior. I personally dont like the word Object in any of the class names. You could either use some qualification like Poko.Car or use some naming convention like Car (for POJO) CarDa (for data access) CarBiz ( for business domain class)

Or if you dont mind the word object in a class name go for something like CarDto (Car Data Transfer Object)

小开

Use a convention that is suitable among the other code conventions you are using. I personally use the suffix "TO" (e.g. the data transfer object associated to the Customer domain class is named CustomerTO). Also the package structure should convey the intent of each type of class (so.foo.domain.Customer and so.foo.transport.CustomerTO)

小开

Adding DTO or DAO or anything else violates DRY. The FQN is perfectly fine, especially if they're really the same thing.

小开

Data Transfer Object classes should follow the name convention defined in the Java Language Specification:

Names of class types should be descriptive nouns or noun phrases, not overly long, in mixed case with the first letter of each word capitalized.

ClassLoader
SecurityManager
Thread
Dictionary
BufferedInputStream

[...]

Suffixing a class name with DTO or Dto won't tell much about the class itself besides indicating it carries data without any behaviour. So, instead of just calling your objects DTO, it might be worth considering more meaningful names, which convey better semantics for the classes.

Here is a non-exhaustive list of name suggestions you could use:

  • SomeSortOfCommand
  • SomeSortOfConfiguration
  • SomeSortOfCredentials
  • SomeSortOfDetails
  • SomeSortOfElement
  • SomeSortOfEvent
  • SomeSortOfFilter
  • SomeSortOfHeader
  • SomeSortOfInput
  • SomeSortOfInstruction
  • SomeSortOfItem
  • SomeSortOfMessage
  • SomeSortOfMetadata
  • SomeSortOfOperation
  • SomeSortOfOutput
  • SomeSortOfPayload
  • SomeSortOfProjection
  • SomeSortOfProperties
  • SomeSortOfQueryParameter
  • SomeSortOfQueryResult
  • SomeSortOfRepresentation
  • SomeSortOfRequest
  • SomeSortOfResource
  • SomeSortOfResponse
  • SomeSortOfResult
  • SomeSortOfRow
  • SomeSortOfSettings
  • SomeSortOfSpecification
  • SomeSortOfStatus
  • SomeSortOfSummary

Note 1: Whether acronyms or all capitalized words should be handled as words or not, I guess it's up to you. Check the Java API and you will find some stumbles like ZipInputStream / GZIPInputStream. Both classes are in the same package and the name convention is not consistent. HttpURLConnection doesn't show any consistency with acronyms either.

Note 2: Some names listed above were borrowed from this article written by Richard Dingwall (the original article seems to be no longer available, so here's a cached copy from Web Archive).

小开

I read the answers above, I just want to add something. I somehow hate the word DTO, It seems like it is screaming at me. So I try to use Payload suffix. For example, CarPayload.


提交答案