Re: EOModeler and more
Re: EOModeler and more
- Subject: Re: EOModeler and more
- From: james cicenia <email@hidden>
- Date: Sun, 11 Jan 2004 21:47:30 -0600
On Jan 11, 2004, at 9:25 PM, Arturo Pirez wrote:
On Jan 11, 2004, at 10:02 PM, james cicenia wrote:
On Jan 11, 2004, at 8:47 PM, Arturo Pirez wrote:
If I am showing a Portfolio screen which has a couple small lists of
project_requests
wouldn't that best be modeled via the Raw Fetch into a dictionary?
Than up clicking a project_request
I could instantiate the full project_request object.
In reality what you're doing above is forcing two trips to the
database. One to populate your
screen and the other to instantiate the ProjectRequest objects. I
would say that's a more
inefficient use of the database the just letting it get it all at once.
Yes... but most of the time only one or two would be clicked per user
session. I was thinking
that I would have this portfolio object
In particular, if you
can leverage the EOF cache, instantiating the objects can be a huge
win.
<Soapbox>
Also, I take exception to your use of the word "modeled" above. What
you're describing isn't
a modelling phase/step/process/etc. It's an optimization outside the
bounds of your conceptual
model; aka an implementation choice not a design choice. Me,
personally, I wouldn't bother
with the raw rows solution until the page needed to display thousands
of objects. In that case
it would be a poor UI that displayed thousands of objects. I would
then redo the display to
prevent/discourage such a poor display and therefore get back into the
realm where raw rows
wouldn't be needed. :-)
</Soapbox>
If I have thousand of users why should I instantiate full complete
objects for a screen that needs
only to show a small bit of information. In addition, the full objects
will contain a lot of attributes
of type Text. This could be very expensive performance wise.
Also, I did read the Vertical vs. Horizontal explanation and feel
that I have my application now
modeled correctly.
This seems like a non-sequitur to me. Are you working with what
WebObjects considers a legacy
database?
No. Just trying to model my "SQL" database with my application in mind.
I guess it is time start diving headlong into the Framework.
I fear for you :-) I've only twice needed a raw SQL statement in
EOF.
Hmm, than how would you have modeled my above scenario? You would
just instantiate
the complete list of project_requests? Sounds very expensive to me in
terms of performance.
Well, you'd have to benchmark it to be certain. But, as I mentioned
above, two database
trips versus one would encourage me to follow the full ProjectRequest
object route. But if
you're only displaying a handful of objects then IMO you should
definitely NOT be pursuing the
raw rows route.
Also, my EOs tend to contain a lot of methods etc that I end up
needing ;-).
Well I understand that part and my portfolio object will have lots of
methods and one
will to be getting a list.
-James
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.