StrutsHibernateDAO

Let there be no bones about it, Appfuse will get you hooked up with a DAO which makes use of Hibernate, yet is still flexible enough to use another Data Access Implementation. However, there is no harm in discussing it and perhaps by throwing around some ideas we can all learn why things are done as they are.

Introduction

So as not to be too verbose, I am going to get right to the point. In a J2EE application, there is going to be some sort of initialization servlet, filter or plugin (struts) that will ready Hibernate, mostly likely from a hibernate.cfg.xml file (though alternative ways are also possible). The idea with hiberate is to ready a session which can remain open throughout the duration of the view since Hibernate has an amazing ability to load objects lazily (hence saving processing time, power and redundancy). Once open, the Data Access Object (DAO) can make use of this session when retrieving, storing and deleting objects from persistent storage.

Directory Structure

Let's begin by talking about directory strucuture. Your startup servlet, whether it be a plugin, filter or listener, will most likely be underneath your presentation directory struture under a folder with an appropriate name. Next comes your business objects. This is where people start going ever which way. I like to create a model folder, which holds the Data Transfer Objects (DTOs) and the DAO interfaces. Then, in the business folder goes any generic DAO implemenations and then a folder under that for each DAO implemenation. In this case, a hibernate folder. So the directory struture looks like: webapp.presenation.listener - Hibernate Startup Class webapp.model - DTOs and DAO interfaces webapp.business.hibernate - DAO implementations

Typical Flow