| 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
|