Apologies if what I'm about to mention has been discussed to death already, but I'm just having trouble getting my head around a design issue to do with my web apps. A bit of back story... a few years back I made my own framework in PHP4 (it was, perhaps mistakenly, similar in operation to Struts)... it was never released publicly and we used it in-house to create a wide range of sites, for which it worked well enough, despite some major performance tuning and optimisation (the number of things it was doing per R/R cycle was *ridiculous*, as was the number of object instances created)...
Anyway, these days I've pretty much abandoned it in favour of a very lightweight... uhh... I dunno if you'd even call it a framework; it's more of a set of mostly static classes with commonly-used functionality, config arrays, include() based templates with minimal scriptlet code for views, and the odd object instance here and there mixed with Page Controllers to run it all. It's pretty old school really, and while it has much, *much* room for improvement, it's quick and easy and works well for most sites we care to throw at it.
But I'll stop boring you with back story and now bore you with the issue at hand. It's to do with how I handle my "model" as such. What I've been doing currently (and this can change from project to project!) is structuring my model as classes much like this (let's use a blog for example - the code is not meant to be functional, it's more of an example of structure):
Now, if you've got this far, here is my question: how much should I pull into memory as resolved objects? In this example, the BlogEntry has a BlogAuthor object associated with it, which in turn has an ID. When the record is saved, the "toDatabase()" function knows to return the $author->id as to create a foreign key for the DB operation. Vice versa, the "fromDatabase()" function does the opposite - it takes the obtained foreign key ID, and calls "BlogAuthor::FindById($id)" to obtain the object associated with this one.
/* some basic common Record functions as well as some abstract: */
class BlogEntry extends Record
/* define insert or update SQL and save accordingly
/* deletes this object from the DB */
/* converts this object to a record array for use in a web form */
/* converts this object to a record array for a database operation (slashes added, foreign ID's obtained etc.) */
/* defines this object from the given web form record */
/* defines this object from the given database result record */
/* static: answer an array of all BlogEntry objects */
/* static: answer the BlogEntry object with the given ID */
var $author; // <-- this is a BlogAuthor object
I guess this is all simple ORM (object relational mapping)... but how far do you go with this? What if we have multiple objects (lists, collections) associated - do we pull all them in as well? What about objects associated with those objects? I guess Lazy Load could come into play here (like a good man, I do have PoEAA), but it's always confused me and I've wondered if it's overkill for PHP stuff.
So I guess what I'm asking is:
a) is this approach to model data sensible, or flawed?
b) should I be looking at implementing Lazy Load, and if so, what method is recommended (concerning 1:1 and 1:M relations)
c) because each PHP R/R cycle is so fleeting, should I be worried about model/data objects at all? Should I just be playing around with DB record arrays? Is it overkill?
I would love to hear the thoughts and opinions of those here who are much more intelligent and experienced than I. Oh and greetings from Canberra, AU - it's BLOODY cold here at the moment.