Niclas Hedhman wrote:
> On Mon, Sep 8, 2008 at 11:41 AM, Niklas Uhrberg
> <[EMAIL PROTECTED]> wrote:
> ]> I'm a but concerned about the term "role" in the discussion because
>
>> roles are used for something else in modelling.
>>
>
> I agree that AssociationRole should probably be named something else.
> Don't they use "stereotype" in UML (probably something else)?
>
>
Don't know actually, I have forgotten many UML details that never came
to use :=)
>> Possibly one would like to put start- and end dates on this association
>> and this would motivate an association class between them as opposed to
>> just a regular association.
>>
>
> Now you are touching on our starting point some months ago, which was;
>
> public interface Spouse extends Association
> {
> Property<Date> startedDate();
> :
> }
>
If two indepent persons use the same example it must be a good one :=)
> Essentially, the association was a "typed link" with its own state.
>
> I still like this very much, from a "understanding" point of view, but
> we seemed to have opened a can of worms in respect to EntityStores
> ability to implement it reasonably.
>
> I am still not convinced that Rickard's new way is the best way
> forward, and that perhaps some good'ol thinking on solving the
> EntityStore problem would lead to something better... But I am willing
> to go with this now, as it is A way forward right now.
>
I had this construction, the other AssociationRole<x, y> where y is a
class representing the data that belongs to the association.
While I favour the first ( public interface Spouse extends Association
) I was under the impression that it would lead to undesirable class
casting situations, but this may be misguided on my part.
I think the first construction is more intuitive and readable.
Rickard, is this variant more difficult to implement on your part (and
the entitystores)?
Would it still be straightforward to implement it with a "hidden entity"
under the hood?
My second concern is this: association classes are not entities (which
we already discussed) and the fact that they get implemented with
entities will confuse and make the domain model blurred.
What do you think about backward compatibility, I assume that even if
Rickards current implementation gets released, there can be a second,
better but incompatible in the future?
/Niklas
>
> 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
