On Fri, Oct 24, 2008 at 6:29 PM, Edward Yakop <[EMAIL PROTECTED]> wrote:
> How about creational?
>
> EntityBuilder<Cargo> builder = ...;
> Cargo cargoTemplate = builder.template();
> builder.initialize( cargoTemplate.origin() ).set( origin );
> builder.initialize( cargoTemplate.destination() ).set( destination );
>
> Query would be done in similar manner.
I don't like it. We are now back to getOrigin() and it just got messy.
Let's look at the "real" problem before going back to a messy past.
You say you have;
public interface Cargo
{
Location origin();
Location destination();
void changeDestination( @NotNull Location newDestination );
}
which is the "context view" of the Cargo. Why would you pollute that
with implementation details such as @Association and @Property???
The mixin for the above;
public class CargoMixin
{
@This private CargoState state;
public Location origin()
{
return state.origin().get();
}
public Location destination()
{
return state.destination().get();
}
public void changeDestination( @NotNull Location newDestination )
{
state.destination().set( newDestination );
:
}
}
The CargoState declaring the internal structure, i.e. implementation details;
public interface CargoState
{
Association<Location> origin();
Association<Location> destination();
}
Binding together the composite for this context;
@Mixins( CargoMixin.class )
public interface CargoEntity extends Cargo, Entity
{}
Ok... That is the current approach.
And you want to save the "CargoState" declaration, i.e.
public interface CargoState
{
Association<Location> origin();
Association<Location> destination();
}
I fail to see the massive productivity gain you are talking about. And
assuming for a second that the above is not Queryable, I would still
suggest that we perhaps support @PropertyField to declare a Property,
without a corresponding Property in a mixin (public or private).
I agree that Property<type> should most likely never be exposed to
client code and that the context interface (or whatever we want to
call it) provides a view of the composite that the client code needs.
It would also prevent the problem of "random queries" that clients may
do, which may cause problem to remain compatible with over time.
I think the DDD usage of "Repository" to handle queries, creations and
similar is a good thing we should promote.
Cheers
Niclas
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
