Understanding MVC

I am in the process of creating a website from scratch, which is proving to be my first real encounter with PHP. For a while, I was looking at several PHP frameworks out there, but decided that I would rather get to know the language first than attempt to learn a framework.

One of the things I got hung up on was how I could redirect to a particular page depending on the logic of the currently executing page (by doing a redirect on the server). An example would be if you access a particular page for which you need to be logged in. At this point, you would want to redirect the user to a logon page. I searched all over and found people asking the same question, even someone asking how to redirect in PHP the way one does in Struts, which I realize now is not a very sensible question, as Struts is a framework, and PHP is a language.

The answer comes in the form of the Model-View-Controller (or MVC) design pattern. Though I had read much about it and thought I understood it, I had never applied it practically, so it wasn’t until really starting work on this website that I started to make sense of it, as is often the case.

Due to my inexperience with the PHP language, my implementation of MVC is very rudimentary, yet it is proving to work for me. I am using the include( ) function everywhere to pass control from one piece of code of another. How it works is as follows:

I have a folder called actionhandlers (the term maybe being borrowed somewhat from Struts concepts). In this folder, I have a number of PHP files, each representing a handler for a particular action. In another folder called views, I have a whole lot of files representing actual views, which are ultimately the outcome of calling an action.

When a user makes a request to the application, that request is routed through the index.php file at the root of the application, and part of the request is an ?action parameter. Based on the value of the action parameter, the control is passed to the php file in the actionhandlers folder with the same name (so that “?action=login” is handled by code in the “actionhandlers/login.php” file). This passing of control is done by a simple include( ).

Now the action handler in turn will implement some logic, the final outcome of which will be another include( ) statement, mostly including a file from the “/views” folder, but possibly passing control to a different action handler.

This very simple, to the point of being barbaric, implementation of the MVC design pattern has done away completely with the need of trying to do something like a “server-side redirect”.

Now the complexity lies in tying up the web application to the model that backs it. For me, this is rather a gray area. I would think that in most MVC scenarios, the model should have a completely independent API, so that you could easily replace whatever you are doing on the presentation side of things. In other words, your business logic should ideally reside entirely in the model.

I guess that what many of the frameworks out there do is not much different, but like I say, I think it is important for me to get a grip on the language before trying to learn a framework.

Tags: ,

  • helmut

    Very noble for you to do this all yourself first. I think I’d be too lazy if there’s something out there to do the job for me! :o) But it sounds interesting what you are attempting. If I understand you correctly, you only have one base page (index.php), which handles and displays everything?

  • martin

    Yes, that is right. All requests go through index.php, which merely “passes control” as it were, to the relevant pages which contain the actual logic and subsequently the output. But I can’t take credit for this. I borrowed the idea from looking how other frameworks and applications out there do it :-) and I think ultimately that’s the goal, to have requests go through one controller which delegates or dispatches requests.

  • helmut

    Nice… now that I think about it, I do know some frameworks that work in a similar way. I’ve done a lot of work with a Open Source CMS (DotNetNuke) which stores all the “pages” in a database, and just “plugs” modules into the one default.aspx page on every request. Ruby on Rails also works in a similar way, but even more pageless. It has a dispatcher module (not really a page) which receives the requests, and then just returns the processed result. As a developer you put your code into different controllers, models, and views, from which the dispatcher draws the needed parts. Also an interesting concept. The one drawback with such frameworks is the overhead (which you mentioned, I think). I guess that makes your “manual” way better in that the requests will return results much faster.

  • angela

    This is the what I’ve been trying to do all week, but haven’t wuite wrapped my brain around it yet. Wish I could borrow yours (brain) for the afternoon!
    Thanks for the food for thought.
    My experience ha been the same. I am encountering the same problems again and again (particularly unhappy with redirects on login) and I feel like there ought to be a good solution… And, I don’t WANT to learn to use a framework. I want to learn to BUILD a framework…
    Thanks again – wish me luck with MVC! (I’m afraid :O )

  • As somebody else who wrote about MVC — and got reddit’d — correctly points out, in a web context, all MVC is really about is separation of concerns; see http://wardley.org/computers/web/mvc.html
    For my own one-file, no-configuration MVC framework for PHP, see:

  • admin

    Isn’t separation of concerns also what MVC is about in a desktop application context (or any context for that matter)? I don’t know. I haven’t read Trygve Reenskaug’s work. But I don’t think that’s wrong. Maybe I missed the point of Andy Wardley’s article. MVC has certainly proven to be an extremely helpful model, and, although it is a big catchphrase used everywhere, I don’t think it ever pretended to be a silver bullet.
    I further think the term “Desktop MVC applications” is a bit of a misnomer. Many people have implemented this type of SOC in their applications, and never thought about what it’s called. The fact that someone labeled it MVC was purely a helpful way to identify the pattern so it can be catalogued and reused. It’s the same as REST. People say: “We must make sure our web application is RESTful”, but REST is not a new thing; it was already there, and then someone observed it and described it.
    It’s the same as breathing: when a person breathes, they don’t think about all the processes that are going on in their body, it just happens naturally, but biologists give those processes names because it helps to describe things for various reasons. They certainly didn’t come up with the processes, but they were there, and they were observed and given names.
    Whew, I think I’ve gone off on a tangent, but my point is this: (At this point I got tired of writing. Sorry).

  • zahid

    good informative post.


  • fyrye

    I have primarily programed in vbscript/ASP since 2000.
    I know this post is rather old from today’s date, but I’ll post anyway.
    I too had this “idea” in 2003 with ASP server side includes.
    Simply providing a fuzzy logic system to serve what I called dynamic includes based on the querystring or form results of the previous call of the single page. With ASP however it was more of a hassle as server-side includes were processed prior to the vbscript and could not hold vbscript variables.
    In short if your page looked like:
    If ( $this ){
    BOTH include files were served and processed prior to the client viewing the resulting page.
    As a hack way to provide the same feature I manipulated the filesystem object to provide the same functionality.

    As of today the alternative is AJAX in which the request is sent and the result can be displayed dynamically on the same page with out having to ever leave index.php
    In essence it’s as if the user opens a new browser to the page you’re requesting, retrieves the page/information, and then displays it on the source page. (tried the as well with javascript and filesystem object, but with internet security being tightened at that time it was very short lived due to administrative privileges from server to client, though it is possible in .hta)