JPA is one implementation of DataMapper.
One idea of Domain Model with UOW is that it decouples persistence layer
from domain implementation and tracking changes of the domain objects.
Domain Model does not know anything about persistence. When domain
object is created or otherway manipulated it register that it's state
has changed to the UOW instance and when user or service decide to save
state of the domain objects they call UOW method commit() which delegate
work to actual persistence implementation(JPA for example).
So these patterns are not reinventing the wheel again (persistence),
instead it describe how to build effective software with domain model
that is totally independent of EIS layer.
rgds,
markku
On 12/31/2012 06:55 PM, David Jencks wrote:
I'm not familiar with this particular way of describing UOW or data mapper, but
you might consider whether they are irrelevant with ee facilities. The whole
purpose of EJBs is to provide declarative transaction management, which is what
UOW usually means. A tiny bit of googling of data mapper makes me ask why you
wouldn't use jpa. I haven't read Fowler's books for many years, I thought his
refactoring book was really good, but the design patterns ones seemed to me to
be reinventing the wheel as far as ee goes.
thanks
david jencks
On Dec 31, 2012, at 8:18 AM, Markku Saarela wrote:
My use case is to implement Martin Fowler's Domain Model enterprise design
pattern with Unit Of Work and Data Mapper.
This UOW does not work with ThreadLocal in every app server due to thread
pooling.
So only solution to use different UOW storing mechanism in different layers;
session persistence in web container and pass UOW instance to the EJB container
and store it to TransactionSynchronizationRegistry. Of course standalone Java
client could use TrhreadLocal implementation.
In UOW static methods to manipulate current UOW instance (getCurrent(),
newCurrent() etc,) must some how decide which implementation to use.
Markku
On 12/31/2012 06:06 PM, David Jencks wrote:
On Dec 31, 2012, at 7:57 AM, Markku Saarela wrote:
Hi,
Has Java EE spec any API to determine is code running in EJB or WEB container?
no.
Or is there any better way than examine stacktrace?
I'm imagining that you have some library or perhaps CDI code that is called
from both a servlet and an ejb? Why do you care? Just to figure out why
something is working the way it is, or do you need to take different action
depending on what calls this code? You could pass appropriate context
information to the code in question from the caller.
david jencks
Rgds,
Markku
