in reply to One to many, many to one relationships
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: One to many, many to one relationships
by rvosa (Curate) on Mar 12, 2007 at 17:45 UTC | |
Such that I can do: ...with an underlying architecture where the relationships automatically are bi-directional in an elegant way. For example: ...might mean that the $node now holds a reference to $taxon, but the $taxon now also has to hold a reference to $node. So should I then do: ...but then the $taxon->add_node( $node ) sub would likewise need to check if $node already knows about $taxon, and if not make the link in the other direction - without recursing add infinitum. All in all, that's not elegant. So my question was: should the link making be managed by a third object (some sort of manager), to which the set_whatever, add_whatever, get_whatever method calls are re-routed. Or should I do something else entirely? My question is not addressed by database designs, raw sql code, or object-relational mappers. Thank you for your input, though. I'm looking for suggestions for design patterns to deal with bi-directional relationships between objects. I understand that the suggestion for MVC has something to do with the issue (but the term MVC is so polluted at this point it's not unambiguously obvious how to apply it - perhaps the 'C' is the link manager?), so greatshots I think got what I was talking about, and so did graff. I apologize to all others if I've phrased things so poorly that I made you write about databases. | [reply] [d/l] [select] |
by agianni (Hermit) on Mar 12, 2007 at 19:24 UTC | |
| [reply] |
by rvosa (Curate) on Mar 17, 2007 at 00:14 UTC | |
| [reply] |
by lima1 (Curate) on Mar 12, 2007 at 20:43 UTC | |
Then this perl code: ...does want you want I think. Or not? Is there a reason why you want to write your own OO mapper (you said you will have an underlying database)? Update: Fixed Idention | [reply] [d/l] [select] |