Hey,

I'm wondering if I'm doing it right. I always build my applications with service layers. So in front I have my struts layer that communicates with my service layer. My service layer communicates with my DAO layer.

Well know, I manage transactions at the service layer. Because that's where my business logic is. Now before I used hibernate I always passed my connection to my interfaces of my DAO. For hibernate this has off course no value.

Now I created a solution using an ITransaction, this has 4 methods, begin,rollback,commit and end. In the hibernate implementation I close my session in the end. This way I don't have any Hibernate references in my service layer.

So in my service layer for every business process I do begin,commit or rollback and end. All in the try,catch,finally of these methods.

Okay I know if I'm gonna mix transactions between hibernate and another ORM or DAO framework it's gonna fail, but this way my service layer is clean of Hibernate references.

I know I could use AOP for this, but most clients I have don't like AOP to much yet, it's to advanced for them.

My actual question is this a good pattern or more like an antipattern?

http://forum.hibernate.org/viewtopic.ph ... emarcation

I also wanted to note that I already read the hread, but It doesn't say anything about how to get rid of the references to hibernate in your service layer.

http://hibernate.org/42.html
http://hibernate.org/43.html

Hey Christian,

I've already read those 2 also. I search first the documentation, then the forum but not yet a real solution. I was just wondering if there was a solution/pattern where you could let your service handle your transactions without being dependent on hibernate.
ie.: if Hibernate 4 would come out that I only need to alter my DAO and ... but that I don't have to touch my service layer because that's where my business logic is in, and I don't want to alter to much in there?

I'm pretty sure that you should read both pages again. They describe exactly what you want to do.

Hey Christian,

I've read them again, but I still have the feeling they don't describe what I mean. In the 2 pages I never see a service layer that is not Hibernate aware, all the transaction code that is described in those 2 pages are hibernate wrappers around either JTA or JDBC, right? I just want to make sure that if I needed to switch back to JDBC (so no hibernate reference in the whole project, not single library), I'll be able to reuse all of my interfaces without altering them, only altering the implementation of my DAO layer.

I wanted a further extraction layer dependent on nothing but my own objects, the implementation of this layer on the other hand is off course hibernate aware.

Im pretty sure with this interface

It will work.

So a methodn in one of my services looks like this now



If one of the proposed solutions one of these pages actually does this could you tell me which one? I've read them all and as far as I can see they all force you to make your service layer hibernate transaction aware.