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!

 

[Kemik]

I use CodeIgniter in all my apps now. It saves so much time.

I'd suggest you look at their website and the blog video.

 

[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.

 

[Dj_Jestar]

I got half way through that email and gave up as it was/is just a rant, but his point does stand fast. There isn't a single (at least mainstream) PHP framework that sticks to MVC.

But instead of looking at this with a "They must all be crap" mentality, he should be looking at it with a "so perhaps MVC is not suitable" or "Maybe what *I* am doing is wrong"

Simple fact is this. MVC is the most vastly, vastly misinterpreted design pattern. Ever. Too many people have seen it as a buzzword and assume that it must be something on the scale of Agile, XP and Scrum. It is not. It is not a way of life for developers, it is not a stringent development cycle, it is a design pattern. But what does that mean? I hear you cry..

• Model - Business/Domain/The nuts and bolts of your application goes here.
• View - Presentation, and presentation only.
• Controller - Which parts of my application do I want to use at this moment in time/state? I must decided here

That is it. You can satisfy MVC in procedural PHP, without a single class/object. You can even satisfy MVC in one single file. Why? All you need to satisfy MVC is to have your M separate from the V and C, the V separate from the M and C, and you guessed it, the C separate from the M and V.


P.S. Yes, you are mistaken - business logic is for the model. The controller is there to decide which model(s) to run, i.e. what state should the application be in, and then fire off the processes relevant to that state. Usually this is just a case of translating the URI.

 

[Kemik]

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.

That's what I feel an MVC approach is. All my queries are put in models, view shows the template with some php in (if logged in show Edit Profile, Logout - else show Regitser, Login) and then controller is where most of the app takes place.

That's the way people over at CI forums look at it anyway and because it's the only MVC framework I've used in detail it's the way I look at things.

It makes sence to me that way anyway. I suppose at the end of the day it doesn't really matter as long as it works efficiently.

 

[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!

 

[Inquisitor]

As Jestar said, the crazy guy is right about MVC being hugely misunderstood by the vast majority of people, but he then goes on to say that anything other than an implementation of MVC 100% faithful to its definition is useless, which is the wrong way to look at things.

The most important thing to remember about design patterns is that they are there to describe common approaches to design problems that are tried and tested and known to work well, not to define solutions to them that must be adhered to. This is something far too many people miss completely.

 

[JIMA]

Hi,

I've been using an MVC framework with Java so whilst it's not about PHP frameworks in particular I hope the below is relevant.

IMHO the model layer of the application should contain classes that model the business processes. That includes database access but also includes all business logic, validation etc. The controller layer controls how things done by the View layer interact with the business model e.g if the Save button is pressed then the required Save action on the business model is invoked.

In my mind it's very important that each of the layers is kept clean and isolated, in particular the model layer being kept complete with no business code being put into the View/Controller layers. Keeping the business model clean enables it to be reused in other applications either fully or in part.

Perhaps more importantly presenting different interfaces to the application is made much easier and more robust. As an example, a web-service based interface can be added to an existing application, with code invoked by the web-services using the business model to carry out the received requests. If some business code had leaked into the controller or view layers then this would be much more difficult to do.

With inter-application communication becoming more necessary I think it's likely that apps will need to present this kind of interface - certainly the case where I am at the moment.

Jim

 

[Dj_Jestar]

Sic - no problem, I enjoy these discussions.

JIMA - I believe you to be spot on. An example of a View component could be something like (what I use, in Smalltalk/Seaside) is a class that does nothing but render an Unordered List Menu (i.e. a list of anchors - Oddly enough, called UnorderedListMenu..) which, as the sharp witted may have guessed by now, does nothing but render an Unordered List of Anchors.

I provide it an ordered collection of strings to display as the list items, and upon the user clicking, it will return the same value so my controller will then decide which model to invoke.

 

[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.

 

[Dj_Jestar]

$this->View = new Index_View($this);

That's a bit borderline (regarding passing the controller as an argument to the view.) I'm fully aware that many consider the line between view and controller to be hazy at best, but I'd much rather the view answered/returned a value, rather than interact with the controllers API directly.

Although having said that, it's a bit difficult to do on a stateless platform so it may be impossible to avoid.

 

[LazyManc]

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? IMO the most important use of the MVC pattern is controller / view seperation - the only "logic" in the view should be looping for similar content or conditionals to display/ignore blocks depending on conditions passed by the controller.

I store most of the business logic of my (symfony) app in the controller layer, it handles form submissions, manipulates the model, etc. I find that fairly occasionally i'll end up refactoring stuff from the controller layer into the model, generally to adhere to the DRY (don't repeat yourself) principle.

I've got a mate that works as a UI contractor for a fairly large dev firm - the back end guys are developing web apps in Java and strictly adhearing to MVC - it's taken them two years to write an app that you could do in a couple of months with Rails / PHP framework.

 

[Dj_Jestar]

Also to add, it's very easy to adhere to MVC with Rails, and no matter what framework anyone uses, just as easy to not adhere.

 

[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

 

[akakjs]

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

(slightly fluffy answer alert) Whatever way is the best fit for the problem set (solves the question asked, can be maintained, the fastest etc). Programming rarely has a right or wrong way to do stuff; and following frameworks/patterns are just ways of raising the average quality of your code so you produce fewer bugs. Use 'em when they fit, ditch 'em when they don't, but don't try and make your problem fit the solution you prefer.

akakjs