Are MVC frameworks in PHP wrong?

[Sic]

Personally, I don't use a framework for development; I'm one of those masochistic idiots who likes just likes to do that (relatively) low level stuff that other code can sit on top of, but I do like to work with MVC in mind, because it makes a lot of sense to me. However, an article spurred by heckling at phplondon08 seems to call my understanding of MVC into question.

I'm sure that there are hundreds of intricacies that I've either glazed over or missed, but I don't claim to be a guru on the subject, I just liked what I read. A very brief breakdown of my interpretation of MVC would be something like:

Model -> For interacting with a data source. For me, these sit on classes for opening connections to databases/xml and give Save/Delete functionality as well as allowing for custom queries to be run and results to be returned.

View -> All display work is done here. Whether you use templates or markup generation, all that stuff is done here.

Controller -> Application logic is here. This is the page that is visited, and it makes calls to models, decides which views to load, processes forms, all that kind of stuff.

The above article (or at least the email therein) seems to disagree with me there, attributing more application logic to the model than the controller. However, for me, my way seems like a very scalable structure (and it is relatively scalable in my brief experience with working with the classes I've developed!), but I can't see what sort of application logic you'd separate into models and retain logic/scalability.

I've started this because I know there are a lot of pretty experienced developers on here, and I'd appreciate input from you guys on the subject. I've only been aware of MVC for about a year, and I was just shown it by a pretty experienced contractor, then he left. Chances are, I've taken a wrong turn somewhere and created my own stupid interpretation of MVC that works but isn't technically correct! :/

If anyone's got any resources (preferably free, I'm supposed to be saving!) on design patterns, I'd be most grateful - the Zend book only really skims over the subject!

 

[Sic]

You either didn't read my post, or you didn't read that article but thanks for the input. The point isn't just to save time and that's why I've asked the question. I've used codeigniter, qcodo, cake and symfony, then I wrote my own (much, much smaller) version because I'm like that.

In case it's not clear, I'm not asking for MVC framework recommendations.

edit: Just been reading the wikipedia entry for this (yeah, leave me alone!) and I think I can see what they're doing that's different to me - putting business logic into the model as well as data source interaction, so localisation and application-specific data stuff would go in there.

 

[Sic]

That's kinda the point I'm trying to make, though (and the point the other guy is getting wound up about!) - just because a bunch of people [mis]interpret something to be a certain way, that doesn't necessarily make it so. From what I can see, it's Rails' fault because I think they define the model as purely a data access layer, but I don't know what came first.

With regard to what Dj_Jestar was saying, I think I've just not been defining "model" broadly enough. My controller essentially picks and chooses classes to run depending on the application state - some of it might be a little specific but this was the purpose of starting the thread; to define the boundaries between model and controller as they'd been somewhat confused (for me) by that article. I was taking model to be a class that interacts with data only, but it's obviously more than that, and it actually makes a lot of sense (oddly enough!) doing it that way. I guess I was just crediting the controller with a lot more responsibility than it was due.

Thanks for taking the time to illustrate that Dj_Jestar, I'm sure you're getting sick of helping me with crap like this!

 

[Sic]

yeah JIMA, that's the way I've been doing things. Like I said before, it's just a case of my definition of model referring directly to data. an example of a controller that I recently made (doesn't take view caching into account yet - site's not finished!)

<?php
require_once('lib/classes/base.class.php');
	class Controller {
		private $View;
		
		public function __construct() {
			$Content = new Content;
			$Content->PreloadTranslation('1');
			$Content->PreloadTranslation('2');
			$Content->LoadTranslations();
			$this->View = new Index_View($this);
			$this->View->Menu();
			$this->View->Body();
		}
	}
	new Controller;
?>

so yeah, the controller is invoking the class (model) that deals with translations and loading the ones needed to populate the view then invoking the view.

 

[Sic]

my reasoning for that is things like current page number are stored as properties of the controller. From an encapsulation point of view, it'd definitely make more sense to pass the page numbers as an argument, though.

At the end of the day, it's a tool to do a job, if it helps your productivity then does it matter if it's not "strict" MVC?

ultimately, no it doesn't matter, I just wanted to know what's the correct way of doing it