2

We have a web application which uses JSP, Servlet and Hibernate. The design pattern we got is MVC like, which means,

JSP -> Servlet -> Beans (POJO)

Now the question. Once of out developers has inserted the hibernate queries, hibernate session creation etc inside POJOs. Now inside these POJOs, there are methods like getAllEmployees(), getAllAgents() etc. This made it extremely hard for us to change the database tables (we handle database manually, using MySQL Workbench) and use automatic tools to re-generate the POJOs because these methods will be lost.

Now there are 2 arguments. One is that this maintaining hibernate queries, sessions inside POJOs is a good work, because it seems like pure MVC. The other argument is move the hibernatre code to Servlets and call the POJOs just like beans, only to set and get values.

We have not worked in Hibernate before. From above 2, what is the preferred place to write hibermnate code when it comes to hibernate?

Finally, please note we are not interested in Spring or other frameworks, we use pure JSP and Servlet with Hibernate

PeakGen
  • 21,894
  • 86
  • 261
  • 463
  • 4
    what about the DAO design pattern ? – vincent Feb 13 '15 at 16:40
  • Yes. Without using Spring or some other POJO framework it is going to be hard for you to implement the proper DAO-DTO design patterns that @vincent rightly mentions. – Richard Feb 13 '15 at 16:41
  • 1
    From my experience, what I have seen and done is have the Entities (POJOs) separate. They are just the representation of the table associated to it. Then a separate "service" class is written that performs all the CRUD on the objects. So you would have `List agentList = service.fetchAllAgents();` and the Hibernate code would be in the `fetchAllAgents()`. Or `Agent newAgent = service.saveAgent(...);`. I am sure others can handle it another way, but that is how all the companies I have worked for have done it. – Ascalonian Feb 13 '15 at 16:44
  • Usually entity beans don't contains methods to data access, I can suggest you to male ore other layer of Dao object to manage tris situation – Skizzo Feb 13 '15 at 16:45
  • @Ascalonian: You mean add all the database code into one service class?? That will be huge! – PeakGen Feb 13 '15 at 17:06
  • @JustCause - Yes, it can be. But that is how the DAO design works. Check out [this tutorial](http://examples.javacodegeeks.com/enterprise-java/hibernate/hibernate-jpa-dao-example/). You can break it down more into smaller services, but that is up to you. – Ascalonian Feb 13 '15 at 17:11
  • @vincent: This is how we did previously. However we avoided the interface layer, instead used a super class with common method and called to sub classes. – PeakGen Feb 13 '15 at 17:13
  • @JustCause.. have you considered singletons? :) – Richard Feb 13 '15 at 17:31
  • You are essentially comparing two patterns: ActiveRecord vs DAO. See here for a starting point to research further: http://stackoverflow.com/questions/6640784/difference-between-active-record-and-dao – Alan Hay Feb 13 '15 at 17:31

1 Answers1

1

Probably, what you need is another layer of abstraction. Since your pojos are recreated after new migrations, you shouldn't insert code in it (I don't agree with that aproach, but that's just my opinion :-) )

JSP -> Servlet -> NewLayer -> POJO

I don't know where you put your business rules, but in this scenario it will be in the "NewLayer" wich would consist of a "hibrid" layer of service and dao.

I would recommend these readings to rethink your actual architecture:

https://softwareengineering.stackexchange.com/questions/220909/service-layer-vs-dao-why-both

Responsibilities and use of Service and DAO Layers

Community
  • 1
  • 1
Allan Vital
  • 376
  • 4
  • 18