I can see it that way, too. I guess the PDOResultIterator, as I have it, is what makes it possible for me to keep the populating of my models' data inside their constructors.
Personally I've never been a fan of the style of models that use static factory functions.
Code: Select all
$topic = Topic::loadByXXX($stuff);
Doing the loading in the contructor has seemed the most straightforward way. Plus, you get to say that a Topic object is a Topic. Not that a Topic object is a Factory for Topics.
Once I went to the constructor style, I really wanted to keep all the models consistent and to keep the number of parameters in the constructor down. I didn't mind parsing for a scaler in the constructor, but passing in an array of data to use to hydrate didn't sit right.
Code: Select all
$topic = new Topic($id);
$topic = new Topic($name);
Anyway, because my constructors we kept to only taking single, scalar parameters, I needed a way to get collections to load and return me these model objects. Thus was born, the PDOResultIterator which just selects and returns ID's to the collection class to be loaded.
Now that I type this you've got me thinking about maybe altering my models' constructors to also take an array of data to use to construct an object. I guess if I did that I could save a database call per element in the result. (D'oh, I also just realized I've left hard coded the $this->list[] = $row[id]. I'd have to modify that.)
But I think I'd stil end up keeping the PDOResultIterator almost exactly as it is. It really doesn't care what the collection classes select. It just makes sure to return whatever the collections choose to select.
You're probably correct in that it's a bit overblown. There's simpler solutions for handling database results. But I'm not sure I'm too crazy about the necessary changes to my models to support the simpleness of an array of rows. To me the PDOResultIterator has seemed a bit of complexity that bought me a lot of simpleness and consistency elsewhere.
It's always a tradeoff, I guess. You gotta put the complexity *somewhere*, right? I think this is really bumping up against the limit of what you can really do with ActiveRecord. If there's something in an application that this starts to be a problem, it may be time to start looking at a Table Data Gateway, or even just Data Table access. But so far, with all the applications I've been up to lately, I don't think I've hit that complexity limit just yet.