I somewhat agree with Niclas, but the other thing that jumps out at me is
that, rather than
companyEntity.employees().hire( person, ceo );
companyEntity.employees().reassign( person, ceo, cto );
companyEntity.employees().fire( person, cto );
wouldn't it be better to have
companyEntity.hire( person, ceo );
companyEntity.reassign( person, ceo, cto );
companyEntity.fire( person, cto );
This way the employees association the could be hidden completely, maybe in
a private mixin, though if you want to make it searchable I think it still
needs to be part of the public interface which kinda sucks. This is also in
accordance with the Law of Demeter and it just looks nicer to my eyes.
Rich
On Tue, Sep 9, 2008 at 1:42 AM, Niclas Hedhman <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 9, 2008 at 7:30 AM, Rickard Öberg <[EMAIL PROTECTED]>
> wrote:
>
> > That concludes the quick test I did of this. Is this something along the
> > lines of what we want? Any pros/cons to it, and can it be improved
> further?
>
> Reflection; I am sure the devil is in the details, and I am not fit to
> compile all that in my head right now, but if "Role" is a bean with
> references to two entities, and that this will be searchable, why on
> earth isn't it just that the Company references an Entity (the Role)
> which references the "primary Entity" in turn? (Pretty much how we
> have always done it).
>
> interface Company extends Entity
> {
> ManyAssociation<Employee> employees();
> }
>
> interface Employee extends Entity
> {
> Association<Person> person();
> Property<String> position();
> }
>
> interface Person extends Entity
> {
> :
> }
>
>
> Right now, I don't see the advantage that clearly...
>
> Cheers
> Niclas
>
> _______________________________________________
> 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
