Published in Programming and Scripts on Friday, February 3rd, 2006
Over the Christmas break I came across an interesting comment in a post by fellow 9ruler Kyle Neath, where he himself states if you're looking into MVC there's an extremely high chance that any examples you run into will consist of OOP-based frameworks
. I realized that he was right, and that perhaps this isn't such a good thing.
Before I get into this, and you serious programmers get too worked up, I realize that MVC was spawned in an Object Oriented Programming (OOP) world, but the fact is that the ideas behind MVC concepts can be applied to procedural code and simple applications that do not use OOP, and when done well can greatly improve things like code re-usability and the code flow for these websites or web applications.
While working with a couple of new PHP learners over the Christmas break, I found that, aside from the PHP manual, what helped them the most was some guidance as to how to organize their code. Not just keeping similar functions in the same directory, but things like keeping certain types of control structures in controllers and formatting functions in views.
The following example is a simple representation of how a person could lay out their code in the spirit of MVC, without all of the extra OOP jazz that commonly gets included with MVC examples. It is by no means an in-depth look at the possiblities.
For those of you who haven't come across this acronym, it signifies model-view-controller. I'm going to quote Harry Fuecks' succinct description from MVC and web apps: oil and water:
- Model - those functions that wrap calls to your db
- View - the templates / scripts that output HTML
- Controller - the stuff that examines variables like $_GET and $_POST and works out what to do next
To take a few more of the points from the aforementioned article:
- Nannying: tell me how to get organised—clear signposts for where to put my code.
- Don't make me think: I can do this stuff even on my dumbest days.
- DRY: making the same change 50 times is not cool.
- Anti-pasta: help me avoid spaghetti
Lets say that we are writing our own little weblog script - I know that this is a tired exercise but it is a good example.
If I was going to lay this out the MVC way, I would have the following breakdown for my functions:
This could be a set of elseifs that call the correct functions and views provided a condition matches.
These functions would be those that fetch the data being requested. You could put data handling/manipulating functions that don't involve xml/html here too, so in the case of our weblog script, any filters being used - for example to change the unix timestamp of a stored post to something fancier - would go here.
Functions in this category would be things like a loop that would take an array of post data passed to it and create a list of post titles for category archive pages. Another example would be a function that takes post data and formats it into an RSS or ATOM feed.
The code above is a simplified example of something that could be used as a controller. It is important to notice that the controller will do different things based on the request made to the server, and that for each request it first fetches data, which it then passes to a function that can handle that data.
In the first case, the function cms_fetch_data is told to get 15 items from the database for the home page and then to pass that on to the view for the home page. In the second instance, cms_fetch_data is told to get 15 items for the category listing of the category 'catname', which is then passed onto the view for a category listing page.
The thing to really understand here is that by building your web application in this manner, it can allow* you to apply concepts like Don't Repeat Yourself which can not only make maintenance faster but build time for new applications faster as well.
It also makes it simple to decide how to break down the functionality of your application, and in effect, how to write your functions. By that I mean, you know that a function contained in views should not contain control structures or database requests.
Using this method also allows for building in things like caching with ease - not only of the final output, be it html or rss, but queries to the db.
* Note: I say allow because you need to do more than this to really appreciate a DRY environment. For example, implementing consistent DB structures could allow you to use the same functions for your weblog module as you would for a module that makes pages for a website.
Anyways, these were just some things that I thought I would share with the readers of this blog after having seen the results when outlining these ideas to new learners earlier this year.
If anybody out there is interested in hearing more, or seeing some more in depth examples of structuring simple applications in this manner, please let me know in the comments and maybe I can flesh something out in a future post.
Sitepoint's web devlopment books have helped me out on many occasions both for finding a quick solution to a problem but also to level out my knowlegde in weaker areas (JavaScript, I'm looking at you!). I am recommending the following titles from my bookshelf:
I started freelancing by diving in head first and getting on with it. Many years and a lot of experience later I was still able to take away some gems from this book, and there are plenty I wish I had thought of beforehand. If you are new to freelancing and have a lot of questions (or maybe don't know what questions to ask!) do yourself a favor and at least check out the sample chapters.
The author line-up for this book says it all. 7 excellent developers show you how to get your JavaScript coding up to speed with 7 chapters of great theory, code and examples. Metaprogramming with JavaScript (chapter 5 from Dan Webb) really helped me iron out some things I was missing about JavaScript. That said each chapter really helped me to develop my JavaScript skills beyond simple Ajax calls and html insertion with libs like JQuery.
Like the other books listed here, this provides a great reference for the PHP developer looking to have the right answers from the right people at their fingertips. I tend to pull this off the shelf when I need to delve into new territory and usually find a workable solution to keep development moving. This only needs to happen once and you recoup the price of the book in time saved from having to develop the solution or find the right pattern for getting the job done..
Comments and Feedback
I think this is a great way to get more folks to run pseudo-MVC environments while it also gets yer tastebuds wet for something more...enter Rails.
Having to manually connect views to models via a central controller seems kinda clunky though.
This is one of the reasons I like the Fusebox framework.
The framework is not so much about making you write classes, and more about organizing the design and development process.
Sure I need to edit some XML files but if I can write code for a website I can write some XML.
There are different ways to do this, but I was trying to keep this simple. I'm not sure if I would call it clunky... maybe direct..?
Me too :)
> There are different ways to do this, but I was trying to keep this simple. I'm not sure if I would call it clunky... maybe direct..?
No no, I didn't mean like that. I'm comparing to Rails (and I would think most MVC's) where the connection is inherent. I like your solution, don't interpret that comment as negative criticism.
Not at all, Justin! I hear ya too...