[eluser]jedd[/eluser]
I can't imagine splitting my current forum controller into thread, post, and forum components, and/or my message model into something similarly segregated. As in, I really can't imagine
how I'd do such a thing .. partly because it'd be a big carve-up of what I've got now, but mostly because my brain just doesn't work that way (yet).
My message model - used by my forum and mail controllers - is about 1200 lines, or 560 lines of actual PHP. I feel that this is Quite Acceptable in the size & performance stakes. It's not complete yet, but might blow out by another 20-30%. Still within the Acceptable Size region, IMO.
ORM's - never seen the appeal, but I'm not an OO type. If I were, and it was a new project with a new database, I'd probably go for a native OO DB (say db4o) rather than trying to squeeze a conventional RDBMS like MySQL into an object-mapping glove.
My approach of only one model having write-rights to a given table has worked well for me to far, though I did have one occasion where it was a bit tricky to maintain that approach. I have fairly modest requirements and a fairly modestly scoped project, so this might not scale so well for you. It does, as you say, provide for a non-ambiguous policy across your entire codebase though, if you can sustain it.
Oh, and when you talk of models being agnostic - do you mean, presenting data to the controller in a schema-agnostic way, or in the sense that one model shouldn't know anything about the schema outside its own area of interest/ownership?
