Edward Yakop wrote:
> But how about domain method that wants to return query?
> Who's responsible to close the unit of work.
> Would we be able to reattach query to another unit of work but still
> attach to the module that it was created originally?
I've done some tests by creating a UoW in the domain, doing a query, and
before returning I pause()d the UoW. Example calling code:
public List<String> productNames()
{
Query<Product> products = productRepository.findProducts();
products.orderBy( orderBy( templateFor( Product.class ).name()));
List<String> names = new ArrayList<String>( );
for( Product product : products )
{
names.add(product.name().get()+" ");
}
return names;
}
This is in the app layer, and the productRepository service is in the
domain layer. ProductEntity has module visibility in the domain layer,
so it cannot be accessed in the application layer.
The repository is implemented like so:
public Query<Product> findProducts()
{
UnitOfWork uow = uowf.nestedUnitOfWork();
try
{
return uow.queryBuilderFactory().
newQueryBuilder( Product.class ).newQuery();
}
finally
{
uow.pause();
}
}
This is with the new API for nested UoW's that are started from a UoWF.
If there's already a UoW in progress this is set as a nested UoW, and
otherwise it is a UoW on its own. We do a query in the nested UoW, which
has visibility of the domain module, and then pause() the UoW before
returning.
When it is paused entities can still be accessed from it, and there's no
trouble working with, and there's also no need for calling clients to
complete() the UoW. Once the reference to the Query is let go of the
whole thing will be GC'ed. Plain and simple!
This would be used for read-only methods whose responsibility it is to
find some data/entities and return it, but which the client should be
allowed to continue to work with. If you want to do modifications to the
state this is done by calling methods in the domain layer which does
these, and then do uow.complete() instead of pause(). This then clearly
differentiates between read-only work and operations which modify state.
I have the above code working, so it's not just theory. The question is:
is this a good way to do it?
One major problem I noted with nested UoW's that get a new module is
that if you do UoW.complete() on a nested UoW then the state gets pushed
to the parent UoW, and that will cause errors since the entity types in
the nested UoW are not available in the parent UoW. Not sure how to
handle this. The communication between nested UoW's has to work better I
think.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev