Hello,

Today i have looked at a couple of examples which uses hibernate and are based arround the MVC pattern. I looked at "appfuse" (also called "struts-hibernate"), "struts-resume" and "xpetstore".

In all these examples the Controller part of MVC is aware that Hibernate is used in the Model. My o'reilly struts book says that should be avoided in most cases, the Model should be replaced without changing code in the Controller and View part.

Is there a example available which really seperates het Model part of the rest and still uses hibernate? If not, could someone give me a advice where to place the sessionfactory variable and where to start the transactions in a simple example? It shouldn't be code, a small text (maybe a pattern) on where to place the hibernate code (buildSessionFactory, beginTransaction, e.d.) should be enough :-)

Thanks!

Hello -

I am also curious about others' approach regarding isolation of hibernate within applications.

What I have done in our web applications is this:

- isolate all hibernate access to static methods in a "PersistenceManager" service.
- use a filter to establish/remove threadlocal session(this filter is tightly coupled with the PersistenceManager, but...)
- queries are generally built from a generic specification, such as Map with criteria which can be translated to name/value pairs in a where clause, or externally configurable queries which are populated with model beans using some generic translation

This way, the controller (in general) doesn't care about hibernate (or whatever mechanism is used). It only cares about (a) the PersistenceManager which houses very generic methods which in turn execute hibernate queries and (b) the PersistenceManagerException which will wrap any exception thrown underneath.

I had the challenge of migrating a tightly coupled (to both controller and view) persistence mechanism to hibernate. This transition has been substantially eased taking this route of a implementing generic persistence service. It makes the system slightly more complex, but it is definitely worthwhile given the ability to provide a nice layer of abstraction.

tyson

Thanks for the reply tyson. Your approach seems cleaner then the examples that i looked at. But it's imho not perfect yet.

I was just looking over the documentation again and got the following idea:
Why not init the SessionFactory in the model it self. Functions like openSession() and beginTransaction() will be placed in the business function. For example a business methode:

function insertUser(UserData ud){
Session sess = sessions.openSession(conn);
Transaction tx = sess.beginTransaction();

HibernateUser hu=new HibernateUser();
hu.setUserData(ud);
sess.save(hu);

//endTransaction()
}

This way the Controller doesn't know anything about the model, not even that it uses hibernate. The UserData parameter passed in the insertUser() function is just a data object with getter en setters.

A flaw in this method is transaction support. For example i have 2 business methods: insertUser() and insertUserIntoLDAP(), the controller calls:

insertUser();
insertUserIntoLDAP();

When insertUser() fails insertUserIntoLDAP() shouldn't be be executed, cause we can't have a user in ldap which isn't in the database.

Anyone can comment on this?

The way I typically do this for web apps is to use a filter in front of the controller and the view. I actually don't do this for HIbernate, as I typically utilize Hibernate behind an EJB layer. But I use it with great success for anything which I don't want clutterring up the controller.

As far as you book, it depends on how you are utilizing the controller concept. Your struts book is of course talking about the specific way struts uses this pattern. But I have been involved with projects where the controller is meant to coordinate all system interactions for a given request, not just "where do I go next".

As far as a cleaner MVC implementation, take a look at the Tapestry project. There, part of your request cycle could be starting a transaction and opening a session at the start of the request cycle and closing and commiting.rolling-back at the end. And, the Application impl would be an ideal place to hold the Hibernate SessionFactory.


You do realize that the other extreme is a possibility in your set up, right? insertUser() succeeds, but insertUserIntoLDAP() fails. Now you have a user in your database who is not in LDAP...

Thanks for the reply, i think i've got enough information to get started. Next week i'll be doing a prototype with hybernate en struts.


Yup :-) These 2 function calls should be in a beginTransaction() and endTransaction() try/exception/finally block.

And how are you going to get LDAP to honor a "beginTransaction() and endTransaction() try/exception/finally block"?

When my insertUserIntoLDAP() fails it throws a exception, i catch it and ask the transaction object of hibernate to do a rollback(). This will cause (when i understand it right) a rollback of the inserted user which was inserted by the function insertUser(). Isn't that the whole point of transaction or am i'm missing something?

Sorry didn't realize that the code you posted was in response to another post.

I thought that that was how you were trying to structure your code. You acknowledged the one possible data-integrity issue; I was simply pointing out the other possiblity based on that code.

No problem :) Still thanks for the support!