Hey,
Niclas and I have today been discussing the "temptation" with being able
to add concerns and sideeffects which are not part of the Composite
declaration. Effectively these would be able to handle quite a lot of
the usecases which UoW state change notifications and vetoes were
supposed to handle. As already mentioned, the state change stuff messes
up UoW quite a bit, and for some usecases it is still not enough as it
is lacking detail in the events.
The danger, of course, is that the ability to add these things "from
outside" gets us into the same messiness that AOP had with the
"pointcuts can add anything to anything, anywhere" deal.
The proposal we came up with, which we can sort of live with and also
makes sense, is that it is possible to declare concerns and sideeffects
using the fluent API for composite declarations in ModuleAssembly. This
makes all assignments explicit, and there's no way that a generic
declaration can "seep" into places it wasn't supposed to go into. Example:
assemble(ModuleAssembly module)
{
module.addEntities(MyEntity.class,AnotherEntity.class).withConcerns(SomeConcern.class,
AnotherConcern.class).withSideEffects(SomeSideEffect.class);
}
---
The idea here is that there *is* a division between the developer
responsibilities and the assembler/deployer responsibilities, and the
above would cater to the latter.
The end result will still be visible by using the visualizer, which will
show the combination of the concerns from the Composite and those from
the assembly.
What do you guys think about this? Does it seem like a decent compromise?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
