Re: Expanding Import
Re: Expanding Import
- Subject: Re: Expanding Import
- From: "Jerry W. Walker" <email@hidden>
- Date: Wed, 8 Mar 2006 11:54:56 -0500
Hi, Arturo,
On Mar 8, 2006, at 9:33 AM, Arturo Perez wrote:
Jerry W. Walker wrote:
Hi, Scott,
On Mar 7, 2006, at 8:16 PM, Scott Winn wrote:
Thanks much to everyone for the help. Let me know if anyone hears
a good rule of thumb for what does and does not need a relationship.
In my experience, however, I've seen two approaches to all but the
primary rule of thumb above.
One says put all the relationships in your model as bi-directional
and prune them only if (and when) they cause problems. This
approach tends to make your initial coding easier because you can
simply assume, for any but a relationship to reference data, that
the relationship is bi-directional and use it as such (in the WO
way :-) ) without thinking about it a lot. When you find a
problem, as you have, determine the offending relationship and
prune it. This approach tends to be followed by the "Make it work,
make it right, make it fast" school of developers.
The other (followed by strong XP advocates) says to only add
relationships, and only in the direction required, that are needed
to complete the immediate requirement. Never add anything
(relationship, attribute, method, class and so forth) for some ill
defined future need. In XP terms, only add what's needed to
implement the current story and nothing more.
Hi Jerry,
Nice precis and helpful information.
Thank you. I was kind of desperately hoping that it wouldn't start a
flame war between the two "schools". :-)
I'm not an advocate of XP and your example above shows one of the
reasons why. For me, the primary objective is to model the data so
that I understand what the customer is saying, what I need to
provide, and the best way to implement it. Following the XP
approach would lead to a rather ad hoc data model, IMHO.
I used to teach classes in software process and was a firm advocate
of the "model EVERYTHING" in the specifications (let alone the Entity
Relationship Diagram) before starting on the code. I was much later
involved in an Extreme Programming (XP) project, which I considered
to be glorified hackery at the time. I approached it with as much
fervor as I could muster, knowing that it was bound to fail. When it
failed, I wanted to be able to say, "We gave it our best and it just
doesn't work."
On the contrary, it worked far better than any process I had used
before. That project made me a sound advocate of XP, but with caveats
that I would be pleased to share with anyone who asks. One of those
caveats is to try to avoid being a purist. I tend to put more into
the EOModel than needed up front for the very reasons you mention.
There are XP purists who might argue, but it was difficult enough
just succeeding with pushing XP through as the company process that
I've never been overly worried about purism (in my own estimation,
others would argue :-) ).
Note that I am not saying put in all Entities you can imagine with
every conceivable relationship. My position is that you put in all
the Entities you know you need and all the relationships you think
you need as well.
I definitely agree with you on the Entities, I'm less strongly in
agreement on the relationships. I generally try to add all the
relationships I know I'll need, but otherwise stick to the XP
approach. On the other hand, for systems for which I'm comfortable
that they won't be pushed hard, I add nearly all bidirectional
relationships to keep it easy and then prune where problems occur.
If it seems to be a system for which efficiency might be a major
concern, then I tend to stick to unidirectional relationships,
particularly in the areas that Chuck mentioned.
But I probably am of the MIW-MIR-MIF school of thought. Any
suggestions on how to pronounce that :-) ? mew-mer-mif...
ROFL!! I didn't know how to pronounce it, but will probably use your
suggestion from now on. :-) Kind of follows Julius Caesar's
pattern: "Vini. Vidi. Vinci."
Regards,
Jerry
--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial
Strength Internet Enabled Systems
email@hidden
203 278-4085 office
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden