I would not remove the methods as this is more according to the law of demeter.
I'd also have the nestedUoW() method of UOW use the
module().uowFactory().nestedUoW() internally.
This kind of paused readonly uow is then quite common in repositories?
Perhaps we should support that directly in the queryBuilderFactory or a
decorator thereof ?
Regarding the communication between nested UOWs. What should the default
behaviour be for completing nested uows.
Why don't they just get paused if they are nested instead of completed and then
completed when the outer uow
completes? So that the state changes are on hold until the outer uow completes.
As the outer one is not able to
access the changed states anyway that should be no problem?
Michael
Rickard Öberg schrieb:
> 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
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
