Wes Wannemacher on 12/11/07 15:05, wrote:
I have a judgment call to make now and wanted some input. At first I
was hoping to create this in a non-IoC fashion. This was simply to
keep the dependencies at a minimum and concentrate on integrating JPA
and struts2. But, in many spots, the JPA docs indicate that the
EntityManagerFactory should be injected (although it isn't that hard
to instantiate by hand). I've thought about using Spring, which will
make things pretty easy with it's transaction management and DI. It
has been suggested to me to use the JpaTemplate, but while I was
reading the JavaDoc for it -
http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/orm/jpa/JpaTemplate.html
It indicates that new projects should use a DAO with a shared EM injected.
If I make DAOs, I may skip Spring altogether.
Also, I could do the transaction management in the DAO implementations
or try to hook into the transactional management of an ee server. If I
manage the transactions myself, it will make mailreader work in non-ee
servers as well. However, if this is a "best-practices" example, I
should probably use the ee server. What do you guys think will be the
best approach.
Hi Wes,
didn't we chat on the OpenJPA list about this when we were both getting into the
subject over the weekend? I haven't had time to finish my implementation of JPA
+ S2 yet but I'm getting close.
I think your initial instinct to keep Spring to limited use only is good, since
adopting the Spring framework without enough consideration invariably leads to a
completely 'Springified' app which then creates immense inertia against moving
it in any other direction.
One thing that interests me is the ability to plug in any IoC container, but as
you point out it's the transaction management which is key and it's foxing me at
the moment.
I've tried the hard-coding route - I ended up with 10 lines of code for every
method of which only one was business code and then gave up because I don't want
to write my own transaction management framework. I'm currently struggling to
use Spring but without giving in to its demands to add in DAO superclasses and
so forth.
Unfortunately outside EJB containers, the only transaction management framework
I know is Spring and it's not exactly snap-on.
Presumably for the mail-reader it's sufficient to use transaction management in
the OpenSessionInView, hard-coded with only one type of transaction with no
authorisation management?
Regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
