Model / View / Controller, aka MVC, is a software writing paradigm that you'll see a lot of in many different corners of the software industry. This is basically a great way to split different distinct areas of software development into different files or areas.
One thing to know about MVC is that there are a ton of different interpretations of how this works. You'll see different layouts, ways of doing things, and directory structures, amongst other things. Basically, when you pick up on a new project, you'll just have to ask how they do things. They might follow a frameworks' way of doing things. They might have their own way of doing things. They might not do MVC at all.
Rest assured, MVC is a very productive way to work and helps break large projects into smaller and more managable pieces. It also helps with security, by breaking tasks into familiar patterns. These patterns are very repeatable and very readable. When you do code reviews and audits, you'll start seeing familiar patterns in the code, which helps you see where you might have done things wrong.
What make up these different files or areas of MVC?
Models - This constitutes your data and database. In the traditional sense, you are modeling your data in your application. What does that mean? Again, there are many different ways to interpret this. I'll offer a couple of interpretations here.
In the traditional sense of modeling data, you design a class that looks like your database. Your class would contain private properties that exactly match your database fields. Each operation on the data would pass through that class. On a simple level, you would use getters and setters to read and write your models. These getters and setters are basically public class methods that act as helpers to read and write. In many frameworks, you can generate these classes using command line systems.
Another way of interpreting a model is a class that includes methods that directly include the database calls within each class method. In my opinion, this is the most flexible and powerful method of doing models, albeit, not exactly traditional.
Views - Views let you design your HTML within a separate file. This is great if you have designers that work on HTML, but don't understand all the backend code. We just want to give them a nice list of variables that they can use in their designs.
Controllers - Controllers bring everything together. Within the controller, you combine the models and the views. Essentially, you're controlling everything.
How does all this look? Let's create everything we need for our employees application.
This code should be put into indexmodels.php in your webroot directory.
<?php
namespace IndexModels;
require_once "db.php";
use \database\db;
class indexmodels {
static public function index() {
$db = new db;
return $db->query("select lastName, firstName from names")->fetchAll();
}
}We've defined a simple method that simply returns our results from our query.
How do we use our new model in our index.php file?
This code should be put into indexviews.php in your webroot directory.
<?php
namespace IndexViews;
class IndexViews {
// $employees is a list of firstName and lastName
static public function index($employees) {
?>
<!DOCTYPE html>
<html lang="en" dir="ltr">
<head>
<meta charset="utf-8">
<title>Employees</title>
</head>
<body>
<?php
// echo the results to the browser
foreach ($employees as $res) {
echo "<div>{$res["lastName"]}, {$res["firstName"]}</div>\n";
}
?>
</body>
</html>
<?php
}
}This code should be put into index.php in your webroot directory.
<?php
require_once "indexmodels.php";
use \IndexModels\IndexModels;
require_once "indexviews.php";
use \IndexViews\IndexViews;
// pull results from database
$results = IndexModels::index();
// push results into our view
IndexViews::index($results);We've just created a simple MVC application.