Hey,
Currently nested UnitOfWork's are created using uow.newUnitOfWork(). The
problem with this is that the new UoW will have the same module as the
original one. If the root UoW is created in the UI layer, then domain
code wanting to do something will not be able to access what they really
should be able since, the UoW they are handed from the UI layer doesn't
see the internals of the domain layer.
To fix this I suggest that starting nested UoW's is handled in
UnitOfWorkFactory instead, since a UoWF is associated with a module, and
when a UoWF is injected it is going to be "my own".
So, if domain code wants to continue an already ongoing UoW, but be able
to access the system from "its" point of view, then it would do
something like:
@Structure UnitOfWorkFactory uowf;
void domainMethod()
{
UnitOfWork uow = uowf.nestedUnitOfWork();
.. do things with the uow which can see
everything in "this" Module ...
uow.complete();
}
This way the code will be able to see things that are hidden from the UI
layer that initiated the "big" UnitOfWork.
However, if you have the opposite situation, that UI code is handed a
UoW from the domain code, and which it wants to continue with, but in a
nested UoW, then one could do:
uow.module().unitOfWorkFactory().nestedUnitOfWork();
UnitOfWork.module() is a new method in UOW that returns the module it is
associated with. In this case the code that executes it does not have to
see anything at all really, it is just gluecode which reuses the scope
of the existing UoW, but in a nested fashion.
Does this make sense?
If yes, then I would also suggest that we remove
uow.compositeBuilderFactory() and uow.objectBuilderFactory(), since
these methods can be trivially reached from
uow.module().compositeBuilderFactory() and
uow.module().objectBuilderFactory(), respectively.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
