Hi Patrik,
belongsTo isn't bad idea but we have more use cases. For example:
Entity Invoice {
scaffold
- @Address address
- Set<@InvoiceRow> rows;
}
Entity InvoiceRow {
belongsTo Invoice
String name;
- @Product product;
- Integer noItems;
- @Price itemPrice;
- @Price totalPrice;
}
And now you need reference to row (which belongs to some Invoice).
Entity TaxReport {
- @BankDoc bankConfirmation;
- Set<@InvoiceRow> vatItems;
}
Or you need full 'scaffold' operations above InvoiceRows. It will be
nice to have possibility to specify which relation is aggregation and
which one is association. Some entities have both. However I can work
with existing solutions and don't see for what we will use it in
process of generation. Maybe just to check that relationTo from other
entities will be checked against list of belongsTo entities (also
inside module). We can also generate different cascade in entities.
For me it will be useful for GUI generation (but I can do it with
hints). For Invoice screen it will generated as embedded entity. For
TaxReport as search item for making association.
Pavel
On Thu, Apr 22, 2010 at 6:59 PM, Patrik Nordwall
<patrik.nordw...@gmail.com> wrote:
>
> What do we need to improve related to aggregates?
>
> To clarify the terms, I'm actually talking about composition (filled diamond
> in uml), but I call it aggregate because that is the term used in DDD. See
> our description here:
> http://fornax.itemis.de/confluence/display/fornax/3.+Advanced+Tutorial+(CSC)#3.AdvancedTutorial%28CSC%29-Aggregate
>
> Two important rules for aggregates:
> - Only the root entity can be linked to from other entities and the
> contained entities and values are only accessible through the root.
> - Only the root entity can have a repository, i.e. it is not possible to
> fetch and save contained objects separately
>
> Right now we can do define aggregates with 'not aggregateRoot'
>
> Entity Planet {
> gap
> String name key;
> String message;
> - Set<@Moon> moons opposite planet;
>
> Repository PlanetRepository {
> findByKey;
> save;
> findAll;
> }
> }
>
> Entity Moon {
> not aggregateRoot // belongs to Planet Aggregate
> String name key;
> - @Planet planet opposite moons;
> }
>
> The first thing we should remove is the limitation that this can only be
> used for Entity. There is no reason why it shouldn't be possible to do the
> same for ValueObject.
>
> Maybe it would make it easier to understand/read by using something like
> 'belongsTo' like this:
>
> Entity Cargo {
> - TrackingId trackingId key
> - Location origin required
> - Location destination required
> - Itinerary itinerary nullable opposite cargo
> - Set<HandlingEvent> events opposite cargo
>
> }
>
> ValueObject Itinerary {
> belongsTo Cargo
> - Cargo cargo nullable opposite itinerary
> - List<Leg> legs
> }
>
> ValueObject Leg {
> belongsTo Cargo
> - CarrierMovement carrierMovement
> - Location from
> - Location to
> }
>
> belongsTo doesn't really add any more information to the model than 'not
> aggregteRoot', but I think it would be good to introduce it anyway, as an
> alternative syntax.
>
> Do you think we need something else?
>
> For Google App Engine we added hint="owned" for references, but I think that
> was wrong. Specifying ownership on the associations doesn't really make
> sense, does it?
>
> /Patrik
> --
> View this message in context:
> http://old.nabble.com/-sculptor--Aggregates--tp28332528s17564p28332528.html
> Sent from the Fornax-Platform mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Fornax-developer mailing list
> Fornax-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fornax-developer
>
------------------------------------------------------------------------------
_______________________________________________
Fornax-developer mailing list
Fornax-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fornax-developer
