Home > database >  Package naming convention for entity, request and dto in Java?
Package naming convention for entity, request and dto in Java?

Time:07-11

For Java and Spring Boot, I have examined various projects and get confused regarding to a proper package naming convention for the following objects in Java (actually the rest, e.g. Controller, Service, Repository are generally the same and no problem for that). So, as an example entity called Employee:

1. Should I use entity, domain or model for as package name for the Employee entity?

@Entity
@Table(name = "employee")
public class Employee {

    @Id
    private Long id;

    private String name;
}

2. I keep request and dto classes in dto package as shown below:

com.github.baldrick.message.request // EmployeeRequest

com.github.baldrick.message.response // EmployeeDto

Is there a better or proper naming convention for these request and dto classes (I prefer Dto rather than DTO for better readibility and I think it is ok)?

CodePudding user response:

1.

Are you going for a domain driven approach then use domain

Does your Object have a relation to a database then use entity

Is it a POJO use model

2

DTO stands for data transfer object. Therefore I think it doesn't really make sense to split between DTO for responses and Request for requests you could name both DTO or Dto whatever you prefer. E.g. you can differ between POST- and GET Dto. And then the answer is easy: Put it into a dto package. If you're using the Request approach I would use Response instead of Dto because it's consistent (I'm a big fan of consistency)


I really like that you put so much thought into this and try to do it the right way. But in this case there isn't the one right way. If you're working in a team you probably already have some convetions in this team and should adjust to the given structure. If it's a personal project it's pretty much up to you and what you're happy with. I e.g. like DTO over Dto and I name my packages in plural like entities, repositories and like to keep it consistent.

So for your own project, it has to work for you.

But when you're collaborating with others you have to decide together.

  • Related