On 2010-01-19 04.09, Stanislav Muhametsin wrote:
BUT, our client didn't want or couldn't use Qi4j at all! So there must
be some way to create new UnitOfWork behind the scenes whenever
required. Most appropriate situation for that would be whenever entering
entity's method and no UnitOfWork is available.
That is impossible, since to get an entity in the first place you have
to have a UoW...
I tried
UnitOfWorkPropagation, but that seems to be suitable only when handling
entities within tagged methods.
I could do
public interface SomeThingWrapper extends SomeThing, TransientComposite
{
// mostly call-through methods to entity
}
However, that is not very convient.
Actually, this is the model I'm moving towards: transient composites in
front of the entities will be encapsulating the usecases, and thus
becomes a natural place to put UoW handling. Or you could also put it in
front of the transients, if you have such a layer (in our case we have a
REST layer that will be invoking the transients).
This is similar to the architecture where you have a service layer in
front which then delegates to the domain model, except I feel it's
better to have transients which are instantiated, as that makes it
easier to handle stateful context for the individual usecases.
Additionally, it is problematic when
SomeThing is given to some other place as parameter, and the code has to
figure out whether the parameter is wrapper or real entity, and if
wrapper, how to get hands on real entity? Some kind of mapping maybe? It
gets too complicated and too much work IMO.
Wrapper? What wrapper?
Now, what really would be great, is that when creating VanillaContext, I
could use contextual fragments to add generic concern to all entities.
These concerns would create UnitOfWork whenever needed prior actually
entering the method. IE same as UnitOfWorkPropagation, but it would
affect on ALL methods of SomeThing.
UnitOfWork has to do with usecases, not factories.
That is currently not possible, as UnitOfWorkException is thrown almost
immediately after going through constraints, if UnitOfWork is not open.
Question is, is there some specific reason behind this? Could it be
better policy to check for UnitOfWork only when it is really needed, ie
when property, association, or maybe private mixin is accessed within
concern? And of course right after concerns, if none of the concerns
accessed entity's state in any way.
Entities can only be accessed through UoW, so if you have an entity you
have a UoW.
Assuming that UnitOfWork MUST ALWAYS be opened whenever even thinking
about accessing concerns of Entities, one could use constraints.
Constraints are for validation. You are mixin terminology wiiildly here.
Then
one would need to create a constraint, which would check some value to
see if vanilla context is being used, and if so, would create new
UnitOfWork whenever needed. For doing this, currently I would need to
add at least one tagged parameter in every method of every entity then -
dirty hack. :) In this situation those method-constraints me and Rickard
discussed earlier would become handy - I would still need to tag every
method though, which is error-prone and dull.
See above.
Of course, if there is some other simple solution to my problem, I very
much would like to hear it. :)
See above for possible solutions. That being said, your code will most
likely have to call uowf.currentUnitOfWork() quite a lot, but that can
be hidden in factories and repositories if you so choose. I don't do
that, as I have no intent of being Qi4j-agnostic, but that's up to you
to decide.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
