CODEWITHSUNDEEP
javahibernatenaming-conventions
Martin Dvoracek
Martin Dvoracek

Reputation: 1738

Naming convention when using hibernate

Me and my team are building java EE app as a school project and we've decided to use hibernate. We also want to make the whole project as nice and clean as possible, so we're trying to follow recommended conventions. Nevertheless I wasn't able to find out, what are the conventions for hibernate files. I.E. I've got a folder /cz/fit/cvut/nameofmyproject/ and there I've got packages controllers, models, utils. In controllers I've got Spring controllers, in models I want to have models for my entities and in utils I've got SessionFactory for hibernate. And now my question:

How shall I name classes in model package? Should it be MyEntityNameDTO, or did I misunderstand the meaning of the DTO and should I just name them MyEntityNameModel? And what should be the proper name for the folder for my DAO classes? Will this simple division be enough for a middle-size project (max ~20 classes/folder) or would it be too confusing? Thanks for any tips from praxis :)

Upvotes: 0

Views: 1766

Answers (2)

JB Nizet
JB Nizet

Reputation: 692151

DTO stands for Data Transfer Object. A DTO is a class which is more a data structure than a real class, usually, and which is created to transfer information from one layer to another, often across the network. It's not a model entity.

A DTO is often used

  • when serializing real model objects is not paractical (because the structure doesn't fit, or because the receiver doesn't have access to Hibernate classes, or because lazy-loaded entities are a problem)
  • when you want to transfer information that is an aggregation, or a complex view, over your model objects (like data of a statistical report for example)

So naming your entities DTO is not a good idea. DTOs and entities are different things. The Model suffix is also cumbersome. Entities are usually named after what they represent: Customer, Company, Player, Order, etc.

Segregating classes based on their technical role is an often used solution. But it tends not to scale when the application grows. I usually have a first level of segregation based on a functional aspect (like customer management, order management, security, etc.), and then a second level based on technical aspects (service, dao, model, etc.)

Upvotes: 4

user1999828
user1999828

Reputation:

UserDAO - interface

UserDAOImpl - implements UserDAO

That is generally what I use. Sometimes the Default prefix like DefaultUserDAO might make more sense if you're creating an interface that you expect others to implement but you're providing the reference implementation.

Most of the time I feel those two can be used interchangeably but in some situations one provides a little more clarity than the other.

There are two conventions that I've seen:

  1. FooDao for the interface and FooDaoImpl for the implementation

  2. IFooDao for the interface and FooDao for the implementation

The former has its roots in CORBA; the latter is a Microsoft COM/.NET convention. (Thanks to Pascal for the correction.)

Hibernate provides the Naming Strategy interface to be implemented by the implementation.

I am listing here few methods.

  1. String classToTableName(String className) – should return the table name for an entity class.
  2. String columnName(String columnName) – handle to alter the column name specified in the mapping document.
  3. String tableName(String tableName) – handle to alter the column name specified in the mapping document.
  4. String propertyToColumnName(String propertyName) – handle to map property name to column name.

Upvotes: 2

Related Questions