Niclas Hedhman wrote:
> Well, I was thinking that even Jini Services are backed by a
> ServiceComposite, otherwise we have too much messy code.
Is there anything in particular that will be too messy? AFAICT right now
there is no absolute need for this. The only minimum requirement is that
there's an interface, so that we can create a proxy. Is there anything
specifically about it being a ServiceComposite that you see as required?
> As for "only entities have associations" --> I think we might need to
> reconsider this, one way or the other.
>
> public interface Car
> {
> SetAssociation<Wheel> wheels();
> }
Ok, what I should have said was that Composites do not have
Associations. Entities currently have, and ValueComposites should have
in the future. Then the above is ok I think.
> Well, I am of the opinion that "Composite" should not be
> instantiatable at all. And that we have an explicit ValueComposite for
> it. That combined with no baseclass is what I would like to see. I am
> even willing to drop "Composite" as a super-interface as well, to make
> it even clearer.
Well, in that case the whole framework is exclusively geared at
enterprise apps, i.e. there's no way to do a POCO (Plain Old Composite
Object). ValueComposites would have restrictions (such as immutability)
that Composites currently do not have, which I think is bad. There's
still a need to do plain Composites which have mutable properties, and
which are not persistent and yet not services. Objects representing
request/response objects come to mind, in an enterprise setting.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
