Search code examples
javahibernatedesign-patternsrdbms

Data access abstraction with Hibernate


Folks, we are developing a game server in Java. First there was JPA/Spring Data/Hibernate, then we've given up (thanks god) and we decided to use Hibernate directly. At this point I can say we are not going to change the technologies for data access, plain Hibernate and native queries if needed.


So my question is about the proper data abstraction at this point. Is there any sense to go with the Repository pattern or for the god's sake give it up an abstract only Session and Transaction processing providing some kind of Unit of Work pattern?

  • In case of the Repository there will be too many implementations with its own methods needed
  • In case of Unit of Work we expose the hibernate Session, but provide the flexibility and encapsulate Transaction management at the same time

What are the pros and cons of each way to go? Any other strategies suggested? Could the DAO pattern be the solution or it is better to work with Session directly?


Solution

  • I would go with Ayende's advice-
    The Session is your database abstraction; you don't need an abstraction on top of your abstraction.