Model-View-Controller (MVC) is a very popular pattern for web application development. It’s used by a who’s-who of application frameworks, including Laravel, Ruby on Rails, CakePHP, CodeIgniter, Laminas (formerly Zend), Yii, Spring, Grails…the list goes on and on.
If you’re new to web application design, you probably picked up a book and slogged through a chapter of academic discussion on the MVC paradigm/architecture. These chapters often speak in baroque generalities instead of doing something obvious like tracing a request through the application.
So let’s do the obvious. And we’ll start by throwing out Models. Not that models are bad – indeed, you should use them. But the application architecture doesn’t really depend on them. And then one thing that it does require doesn’t even get a capital letter: routes. So let’s look at RCV (route-controller-view) because that’s how these apps actually work.
In this example, we’ll use Laravel which is a PHP framework, but the concepts are the same for other frameworks/languages.
We’ll start withe request. This is often someone’s web browser (but could also be a script calling an API). Let’s imagine someone is shopping on example.com. They start by going to www.example.com.
Their browser heads over to https://www.example.com and this request is first handled by your server’s web server, such as Nginx or Apache. The web server is configured to point all requests at an index.php file, which loads the rest of the framework.
The first thing the framework does is pass the request to the router (the R in our RCV). In Laravel, this is a routes/web.php file that you create. The router has rules like these:
- “if the request is a GET for www.example.com, pass the request to IndexController”
- “if the request is a GET for www.example.com/inventory/<number>, pass the request to StoreController with that inventory number”
- “if the request is a POST for www.example.com/search pass the request to SearchController”
So what is a Controller (the C in our RCV)? That’s where all the application logic lives. If your app needs to do some processing to prepare the page returned, all of that work is done in the Controller.
So in these examples:
- the GET request for www.example.com might be just a static page, or it might be fetching some data from the database on what’s in stock, current specials, latest blog posts, etc.
- To handle the GET to www.example.com/inventory/<number>, the StoreController will go and fetch info from the database about that stock number.
- To handle the POST to www.example.com/search (the user has typed in a search term and hit enter), SearchController will query the database to get the results.
Each Controller is a separate PHP class you create. We’re simplifying here – typically you’d have a Controller with different functions for each type of request, grouped together to facilitate code reuse, but this is just an example.
Let’s say someone requests info on inventory item 1234. The Router sends it to the StoreController which queries the database and gets all the info for that inventory item. The next step is to put that into pretty HTML and send that back to the user.
That’s where a View comes into play. The View is a skeleton with all the CSS, JavaScript, HTML tags, etc. and placeholders for the data. So it’ll have the header, footer, and sections for the content. The Controller “hydrates” the view by filling in all the data and then sends the page to the user. Our R-V-C round trip is complete.
Not all of these steps might be required for each request. In the case of static content, it’s possible the Router could just send a static page directly. Or the Controller may not need to talk to the database. But typically, requests follow the Router-Controller-View path.
What About Models?
These goddesses can still grace the catwalks of your web application.
A Model is an object that represents a database row/record (as in a SQL database such as MySQL or PostgreSQL) or a document (in a NoSQL database like MongoDB). Instead of having to write SQL directly, you can do things like
$item = Inventory::find(1234); $item->discount = .15; $item->save();
…instead of writing “UPDATE inventory SET discount = .15 WHERE id = 1234”.
You may recognize this as Object Relational Mapping (ORM).
They’re a great help, but you can write a web app and just write the SQL directory in your Controller if that’s what you prefer. Models are just there for the Controller to work with the database more easily.
There are other components, as well. Most web frameworks include some kind of templating engine to make hydrating views easy (for example, Laravel uses Blade). And frameworks often include helpful components such as session management, authentication/authorization systems, logging and debugging tools, etc.
With the basic Router->View->Controller request flow pattern, picking up any given MVC application framework should make sense, even if you’re new to web development. In the words of the Laravel routes.php file, “make something great!”
I also enjoy using LEBs! I have an empire of little guys for VPNs, larger guys for apps, and big guys for databases and storage. When I'm not in front a screen I'm into German Shepherd dogs, quality knives, target shooting, theology, tabletop roleplaying games, and forest hiking.
I enjoy writing technical articles here on LowEndBox to help people get more out of their systems. You can find me on LowEndTalk @raindog308
- Merry Christmas from LowEndBox! - December 25, 2024
- We are Social Butterflies!Check Us Out Wherever You Browse, View, or Tap! - December 23, 2024
- Let’s Celebrate the Winter Solstice with Awesome Deals and a Free Bonus Code for RackNerd’s Giveaway! - December 22, 2024
Leave a Reply