[eluser]kurucu[/eluser]
[quote author="jedd" date="1253822581"]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).[/quote]
Interestingly, not so long ago neither could I. I previously used my models such that they know about their capability (Aircraft terminology)... I think I mean area of the problem domain in official terminology. The point being that they know about the schema, it's relationships and inner workings, and presented "Discussion", "User Management", "Authentication" (inc permissions etc), "CMS" groupings of functions to the Controllers.
However, in joining this forum and skimming through the various posts, documentation and other references used, I started to feel that a more OO approach would be useful. Indeed, all it has done is split up (and perhaps clarify) a larger model. I have been lucky until now that a change of this size hasn't been a massive undertaking.
[quote author="jedd" date="1253822581"]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.[/quote]Each of my individual models are around 150 lines, so I guess about equivalent after you add them all up with private messaging and whatnot. Although your's sounds more efficient and, well, intriguing.
[quote author="jedd" date="1253822581"]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.[/quote]I am constrained, wrongly so perhaps, by my hosting provider. Perhaps this (and version control) could be fixed by a hosting move. In the meantime, I'm stuck with the gauntlet and MySQL. Assuming I take that route. This is still the question.
[quote author="jedd" date="1253822581"]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.[/quote]Mine's presently modest but with an eye on ambition. Either way, I'd rather have a rule I didn't like following than anarchy in my code. What's more, is that the overheads of ORM have yet to convince me compared to a structure like yours. You present it as personal, and that's its advantage: efficiency and applicability.
[quote author="jedd" date="1253822581"]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?[/quote]The former, for sure, but an element of de-coupling is useful for any changes down the line. For example, my tables have foreign keys, so my newly split models might provide a post table with the ability to: get all posts, get a single post, get a post count, get posts for X thread, get posts for X user, insert and update. Also, all functions returning more than one row have hooks for pagination.
This means to find out about the thread and posts within, I must use both models. Previously, I used a get_thread function which returned the thread header information and all its posts. I use my discussion models as an example, but it applies across the board.
