MVC.. What the heck is that?

Welcome back!

Welcome to the second article in my series on PHP frameworks. I trust you followed the first article OK and you are all fired up to take your knowledge to the next level.

If you didn’t get a chance to read the first article, it can be found here.

 

Help! What is all this MVC stuff?

Imagine this, you’ve just read 3 or 4 posts online about PHP frameworks and you can see from what most people are saying that it could be the way to go for your next project.

You download the framework, get it installed and then…

“What the hell do I do next?”

One of the most common areas where there is a ton of confusion over PHP frameworks is how they actually work. What exactly is the structure?

You may have seen acronyms such as MVC being bandied around, and while you go ahead and Google it, your brain is still a bit scrambled!

But you can relax. While the structure of PHP frameworks are complex, the actual basic architecture of most of the frameworks out there can be explained quite simply. Oh, and we’ll get onto MVC in just a minute.

 

A trip back in time…

If you have ever worked with HTML as well as your PHP coding (and the chances are quite high that you have) you will at least have heard about separating the content from the code. That is, keeping the HTML separate from the PHP code. This is something that has been strongly advocated for a very long time, right?

Of course, as PHP started life as a simple scripting language, it intertwines with HTML very well. But you will know from the times when you have chucked bits of PHP in amongst HTML, and then perhaps sprinkled some JavaScript in there for good effect, that if it doesn’t work it can be a nightmare to track the bugs. And, if you have several pages you may end up copying and pasting code between them.

You will also know, I’m sure, that inline CSS went out with ark and we all keep our styles separate from our HTML.

So how can this little walk back in history help us? If we look at why we are told to separate our display and styles from our coded logic, we can get a pretty good idea of how we would go about designing a framework.

Why separate?

Spend the next few moments thinking about why you think it is a good idea to separate the display code (HTML for example) and the functional code (PHP, JS etc).

Think back to all the times when you’ve copied and pasted code, then changed it to suit the web page. What about the hours you’ve spent trawling through a mix of code to find out why it just won’t show the data correctly (or even retrieve it in the first place).

As you look at the pile of spaghetti code in front of you, you are reminded of why we should separate the different areas of our web app or website.

So apart from being being a lot easier to read, some of the benefits of separating the code are:

  • Faster and easier to find bugs
  • Avoid repeating our code – DRY: Don’t Repeat Yourself
  • Easier to change the part that displays – or to change the part that does the functional stuff.
  • Easier for someone else to come along and maintain the app or site
  • Easier to get help from others
  • Easier to…

Did you spot it? There seems to be a recurrence of the word “easier” in the above list…

OK, all very good – but what about MVC?

MVC stands for ModelViewController. Quite simply, it is how the majority of modern PHP frameworks separate out parts of the code. The MVC architecture has been around since 1979, so it is a well-proven way of organising stuff.

Model

This has to do with your data. More specifically, the Model deals with getting and saving the data according to the business rules that we set for that data. It interacts with the database (or files) and contains the logic for doing so. This can seem a little daunting at first, but panic ye not – we’ll simplify it all down in a minute.

 

View

The View is as it sounds and is concerned with the display aspects. In other words, it deals with the output to screen or rendering the user interface.

 

Controller

The Controller binds everything together and acts as a router. It takes input from the user, interacts with the Model and instructs the View to update.

To give an example of how this works, we can take a typical web request:

  • The browser (via user input) sends a request to the server
  • This is the trigger for the controller to do something with the request (often called an action)
  • The controller then interacts with the model
  • The controller then instructs the view to update and display the correct data

I don’t get this Model thing

The View and the Controller parts of the MVC architecture are relatively straight forward to understand, but the Model does seem to cause confusion. Lets look at some typical models:

User: this may contain the following data fields…

userID

firstname

lastname

emailAddress

Blog Post: this may contain the following data fields…

postID

postText

dateCreated

createdByID

statusID

datePublished

publishedByID

It may at first seem like the models are just the data fields from the underlying data table, but that isn’t necessarily so. The data fields in they model may be all or just some of the fields from the table. The model may also contain fields from more than one table.

In addition to the data fields themselves, the model determines the rules that govern how those data fields are used. For example, applying any filters and queries for subsets of data.

This removes the need for these filters to be applied at the View side of things, and helps to make the code more manageable and re-usable.

 

Right… so MVC is a it clearer now

Good, we have a basic understanding of one of the most commonly supported architectures of a PHP framework. What next?

The different frameworks may have slightly different ways to organise your actual physical files, however all follow a directory structure something along the lines of:

app/

models/

views/

controllers/

 

There may also be a few more folders such as pluginsconfig etc, and this nice separation of the physical files follows the virtual separation of the MVC architecture.

This really does help to keep you organised and simplifies maintenance, bug-tracking and version control.

By now you will be realising how a framework fits together and the basics work. There is more to it, but this foundation knowledge is a great start to shedding some of the skin if confusion that often shrouds frameworks.

 

Summary

In summary then, we have learned that the chosen architecture for most popular modern PHP frameworks is Model, View, Controller (MVC).

We also know that the MVC architecture separates the web app into three logically sound parts:

Model: 

Concerned with getting and setting data according to certain rules that we put in place.

View:

Creates and updates the user interface – the part the user sees on-screen.

Controller:

Routes the requests from the user input to the Model to get/set the data, and then interacts with the View to display that data to the user.

Excellent! I trust this has helped simplify the basic architecture of PHP frameworks for you, and has reduced some of the intimidation of the perceived complexity.

Now you’ve got this far, is a PHP framework for you? We’ve already covered a number of the benefits of using a framework, so perhaps it is time to look at some of the other areas of uncertainty about them.

This is indeed what I’ll cover in my next article… funny that!


To get more of your questions answered, sign up to my newsletter now! Make sure you get all the latest PHP tips and tricks delivered directly to your inbox: