Hi Pierre,
First off, thanks for the response (and thanks to the others who
responded earlier). It is good to hear from someone at Apple who is
familiar with the code. It sounds like the smart thing to do is not
to add keys as class properties directly, since EOF might have some
branch in the future that follows through on the assumption that they
aren't.
I have just begun to really get into the Project Wonder framework,
and it looks like ERXGenericRecord provides nice ways to get at the
keys easily without writing 3-6 lines of code each time (why didn't I
think of the methods that ERXGenericRecord provides earlier?).
Thanks to Kieran for that suggestion.
As to the question of whether writing custom SQL code is poor design,
I certainly don't want to get into an argument about it. I'm sure
sticking totally with EOF for database communication has advantages,
and I spent many, many hours (probably amounting to weeks or months)
trying to keep within those parameters based upon the documentation
that I have read that advocates doing so.
My real world experience taught me the hard way that sometimes (if
you need to do quick optimized fetches on data sets with more than a
few thousand records that span several tables) you can save lots and
lots of time (not to mention lots and lots of memory) just generating
custom SQL to get raw rows. It's far easier to optimize, and you
don't have to deal with the time and memory overhead of encapsulating
the data as a set of full fledged enterprise objects (In a large
hitlist the user will probably not drill down for detail on the vast
majority of these rows anyway). The strategy of fetching the display
hitlist as raw rows and then creating an EO for use only when a user
selects the row for a more detailed view has worked out really well
for me, and I've found that managing the SQL isn't really more
complicated than managing a complex fetch specification. It's felt
very liberating, actually, to code this way, and when combined with
using a connection pool for non-EOF database communication, it's
very, very fast compared to EOF (even when using all the tricks like
prefetching, batch faulting, etc).
I've been using this paradigm for several years now and have yet to
experience any downside. I've had far less grief with it than the
days and days I used to spend trying to optimize EOF to acceptable
performance levels (acceptable from the customer's point of view).
I'm not trying to pretend that this method is the height of clean
design (I'm no more thrilled with embedding complex custom SQL in my
application layer than I am with embedding complex
EOFetchSpecification construction), but it is pragmatic, and I would
encourage developers to at least think through the possible benefits
and harms before simply writing it off as an option (as I did for
years). It's easy to say that it's a bad approach until you've
actually tried it and seen it work.
I would welcome any more thoughts or discussion on the subject, and
again, appreciate the feedback thus far.
Sincerely,
Mark
On Feb 4, 2007, at 11:30 AM, Mr. Pierre Frisch wrote:
Hi Mark,
Before setting primary keys as class properties I would really
question my design. This question typically occurs when you use the
primary to convey meaning about the object and this can usually
better be expressed in the object itself. This will give you a
better object design and a more readable code. In 10 years
developing with WebObjects I am yet to see a problem that could not
be worked around that way. Primary key should left at the database
layer. The application layer should manipulate EOGlobalID you will
save you self and the developer that will fix your code after you a
lot of trouble and time by keeping that encapsulation.
You are right EOF make the assumption that primary keys are not
class property. I do not think anything break in the current
version if you make them class properties and consider them as read
only but that is not guaranteed for the future. Primary Keys are
considered private to the EOControl layer and should only be
accessed directly if you are writing extension to that layer.
As for optimizing there are lots of way of doing it within EOF and
for the same reason you should probably try those very hard before
writing custom SQL code. The same apply here I have used all sort
of delegate and even written custom qualifiers but I have always
stuck to the rule that I do not embed SQL code in the application
layer. If you are missing feature to optimize your application
please file a bug report. I promise that it will be read.
Thanks
Pierre
--
Pierre Frisch
[EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to archive@mail-archive.com
