Here's what I like:
Define a service interface which specifies the high-level business
operations. The implementation of that interface would be in terms of the
business/domain model objects. I'd keep hibernate code out of those objects
to the degree that's possible.
The trick, then, is to use a
>If someone were to implement the sessionFactory as a JCA connector, all of
>this code would become the responsibility of the container. It would also
do
>the propagation of transaction contexts.
I am looking into implementing a JCA connector, by the way
---
The way I handle this is to use a command framework, where there is a
session bean that acts as a command execution context. exception handling
like this can then be built (once) into either the command bean or session
bean. I don't find it necessary to have a different session bean remote
method f
I can see how this would be nice, but hibernate.query.imports already makes
me feel a bit quesy (and can be a source of bugs). I don't really wish to
compound this by introducing a similar thing into the mapping files.
- Original Message -
From: "Donnerstag, Juergen" <[EMAIL PROTECTED]>
T
Hmmm very cool.
Hiram are there any ways in which Hibernate could support / integrate better
with this framework?
- Original Message -
From: "Hiram Chirino" <[EMAIL PROTECTED]>
To: "Urberg, John" <[EMAIL PROTECTED]>; "'Jozsa Kristof'"
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Satu
