Hibernate version: 2.17c

Mapping documents:

Code between sessionFactory.openSession() and session.close():

Full stack trace of any exception that occurs:

Name and version of the database you are using:

The generated SQL (show_sql=true):

Debug level Hibernate log excerpt:

I am working on building a web application and want to use Hibernate. The architecture I think will be JSP --> Business Delegate --> Session Facade --> DAOs --> POJOs --> Database. Is it the recommended approach?

I have build the POJOs and mapping files. Now I am thinking about building DAOs. My question is should I build these DAOs as Stateless Session Beans or just simple java files? Also I am thinking about using POJOs to pass data from server to client. Will I get into any problems with this approach?


Please throw any answer at me. I really appreciate it.

Thanks

with Hibernate I think you dont need DAOs. Instead you can build Stateless Session Beans for each use case you have in your application.

JSP --> Business Delegate --> Session Facade --> POJOs --> Database

Dont you mean ?

JSP --> Business Delegate --> Session Facade --> Stateless Session Beans --> POJOs --> Database


why not use DAOs?

Intermixing business logic with Hibernate API calls is not a good design choice, IMO. DAOs serve a very useful purpose in isolating persistence (Hibernate) logic from business logic.

There are lots of ways to structure Hibernate-based apps. The one our organization uses pairs Hibernate (for persistence) with Spring (for transactions and config management). Here's a good article:

http://hibernate.bluemars.net/110.html

This one is okay, too:

http://www.onjava.com/pub/a/onjava/2004 ... bapps.html

of course, use DAO. Just one example swithing from hibernate 2 to hibernate 3 need to change all hibernate imports. If you also want to take advantage of new features, using DAO helps you a lot: you know where to look at!

IMO, 1 DAO per POJO is too much, if you have a well packaged fined grained domain model, 1 DAO per package is good.
In my apps, generally only one package is necessary for a use case.

I mean, use-case *--1 package (in genaral, you can have reporting use-case that need pojo from many packages).
But this depends on the way you're designing your apps...


About architecture, i personaly use
JSP(view) 1--* Action(struts view controller) *--1 Business Delegate (delegation + business controller) *--* DAOInterface

I use DAO interface because some use case requires pure JDBC (because we just don't have money to rewrite them ;))

Stateless Session Beans are also ok.

I didn't want to add business control on the struts actions because it is clear to me that struts will be replaced (1 year maybe more) but that's only my POV.

Pojo are used on each layer of course.

For long application transaction i use a custom filter + hibernateUtils based on caveatemptor examples, i can switch between short and long session when i want.
For this, i'm using inheritance on business delegate (if businessDelegate is instance of longBusiness --> a long session is automatically with flushmode.NEVER and flush is called only at businessDelegate.commitApplicationTransaction(),... if not, we just use 1 session per http request and commit is called at the end of the filter).

Have in mind that application transaction don't have to be managed in the DAO layer, it's a business control problem.

Hope this helps.