Hi Rickard, One advantage of using extended entity declarations is that it makes design decicions explicit. It is obvious now that if we like to use DomainFooEntity in our domain layer and for contexts and roles that have to be added in the application layer we will use ApplicationFooEntity. This is easy to read and understand.
But if we could define roles that an entity will play later on in different usecases (or technically in different layers) we could keep the hole entity definiton in *one* place. And that would be great! So I would also like to vote for a change to the assembly api, so that we can define on which circumstance an entity will play a defined role. It feels natural to define that an entity in context xyz should play the roles a,b,c and in a different one it should be d and e. Question now would be "How to define when a mixin is available?". So, if we prefer @Optional to @Nullable since it better expresses the intent of what we would like to do, than I would prefer to "bind" the mixin availability to a context and/or a usecase with a availableIn() method on the mixin declarations. regards, Maik 2010/7/6 Rickard Öberg <[email protected]>: > Hi, > > Through the object-composition mailing list, which discusses DCI a lot, I've > come to suspect that it might be important for us to allow public mixins to > be added which are additionally added to the proxy of the composite. > > Specifically, in DCI you would want to declare an Entity as having only Data > interfaces, with CRUD operations and any other Data related operations, and > then add Role mixins "on top" when needed by Contexts. As it is one would > have to change the EntityComposite declaration to include these roles. > Example: > interface FooEntity > extends EntityComposite, FooData, Foo > { > } > --- > If FooData contains the data, and Foo is a particular role used by a > particular context, then FooEntity is tightly coupled to that context and > those roles. If we instead allow mixins to be declared and exposed through > assembly, this coupling goes away. We already have .withMixins() in the > assembly, but previously this did not cause interfaces of those mixins to be > publically exposed. Example: > module.addEntities( FooEntity.class ).withMixins( FooMixin.class ); > -- > With the above, if FooEntity extends the interface of FooMixin (e.g. Foo) > then the proxy for the entity would implement Foo, otherwise not. > > I suggest that this is changed so that the interfaces implemented by mixins > declared in the assembly are also exposed. The above would then lead to a > proxy which implements "FooEntity" *and* "Foo", and can be cast between > these two as necessary. That would allow new contexts and roles > (corresponding to new usecases) to be added without having to change the > entity definition, which would be good (I think). > > The reasonable alternative would be to use extended entity declarations, > such as: > > interface DomainFooEntity > extends EntityComposite, FooData > { > } > > interface ApplicationFooEntity > extends DomainFooEntity, Foo > { > } > -- > Which already works today. > > Any thoughts on this? > > regards, 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
