[ http://jira.andromda.org/browse/HIB-169?page=comments#action_12438 ]
Cédric Vidal commented on HIB-169:
----------------------------------
The hard thing I see with generating hibernate entities and mapping files for
association classes is not in the generation of the actual association class
(you've summarized it pretty well) but in the generation of association ends on
both sides of the association class.
As an example, if you have the following UML diagram:
A
|
B * -------> * C
We would generate in A a composite identifier composed of B and C's
identifiers, that's no problem. And in B, what I suggest is generating methods:
public Collection getAs();
public void setAs(Collection as);
instead of:
public Collection getCs();
public void setCs(Collection cs);
What do you think ?
If we were to agree on that, we would need to answer the following question:
- Do we modify AssociationEndFacadeLogicImpl#handleGetGetterSetterTypeName() to
return A instead of C and AssociationEndFacadeLogicImpl#handleGetName() to
return 'as' instead of 'cs' if the association is an association class ? That
way, all existing templates and cartridges would be compatible with models
using association classes right away. But templates and metafacades willing to
use the real C instead of the A would need to be modified.
- Or is it the responsibility of the templates to deal with that situation ? In
that case, additionnal association class specific methods could be added to the
metafacades and all andromda templates would need to be modified to take
advantage of association classes.
Those two alternatives boil down to the following question: Should we do
smarter metafacades aware of association classes (and soon qualifiers:
UMLMETA-67) or should that distinction be done at the templates level (more
verbosity) ?
I would tend to prefer making metafacades smarter, as this is what andromda
already does with n-ary association ends, in that case,
AssociationEndFacadeLogicImpl#handleGetGetterSetterTypeName() returns a
collection (or a list if ordered). And existing models not using association
classes wouldn't be broken by that enhancement.
The main argument against making metafacades smarter would be that some people
would prefer to generate association ends on both sides of an association
classe differently than what's proposed here.
What do you think ?
> Take into account association classes
> -------------------------------------
>
> Key: HIB-169
> URL: http://jira.andromda.org/browse/HIB-169
> Project: Hibernate Cartridge
> Type: Improvement
> Versions: 3.1
> Reporter: Cédric Vidal
> Assignee: Carlos Cuenca
>
> Association classes support has been added to UML metafacades, but are not
> yet taken into account in the java files and hibernate mapping files
> generated by the hibernate cartridges.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
