In this article we’ll look in more depth at what the MVC architecture is in detail, and what each part is, and why you should be using it.
Why You Should Use It
Without a good reason to use a new structure, framework, technology, or trend, many developers may have a hard time getting motivated to learn a new topic. So, to begin, we’ll first introduce why the model-view-controller architecture is so important, and why you should begin adopting its practices in your next web application.
With the separation of the use of code between the three file types, you obtain a separation in web application logic. You obtain an almost complete separation in programming logic and the interface code (markup and styles), and further separation in the type of logical code for the application.
Basically, a web application or piece of software that follows the MVC structure separates the three main types of functionality into three types of files: models, views, and controllers (as you may have guessed). This allows for each portion to be designed, implemented, and tested independently from any other one, keeping code organized. Keeping the code organized means being able to find what is needed quickly, test features, correct or alter them quicker, and add new functionality with ease. It also means more efficient code, and a better way to re-use code for faster applications.
Probably one of the greatest benefits however is that many developers understand and use the MVC structure for creating web applications. If developers use any of the popular web development frameworks, then they understand and use the MVC structure as well. Because of this consistency, managing a project between several developers can be easier as well.
Now you know why it’s important and basically what the structure’s purpose is, so let’s now look into each portion:
The controller can be considered the “middle man” of the application. It works with the user, taking in data, and then working with the model to get the appropriate data or calculation, and then working with the view to show the response to the user.
When the user carries out any action, it first goes to the controller. It will take in any data, for example
$_POST variables in PHP, and determine what should be done with the data. In short, models deal with handling data and extended functionality. Therefore, the controller’s job at this point is to determine which model should be called, and then call the appropriate function within that model. After calling the function, it will catch the result (usually in a variable).
After it gets whatever information it needs from the model, it will determine what view to send that feedback to, and send the user there.
A model is simply a representation of something we need to deal within our application. It is a “model” for something we must represent in code, such as a book, user, bank account, or whatever. The model is responsible for holding the functions and variables that are involved with whatever it’s representing. You can think of a model’s logic as the core concept to object oriented programming — models are just our “classes”. However, don’t let this confuse you as controllers are technically structured as classes as well.
For example, a “User” model would be a class that represents our user. (It models our user.) It holds variables that pertain to the user’s information, and functions that get the user’s info, set it, update it, get their profile picture, update their status, or do anything else that would require interaction with the database, or otherwise an extensive function (like making a calculation based on user input).
Just like a class in traditional object oriented programming, a model simply contains a collection of similar functions, or functions that deal with whatever the model is representing.
Finally, after the controller requests information from the model it sends it to a view. A view is just like the application’s templating system — there might be a view for a certain type of page layout (profile page), a mobile view, or a view for a particular theme/skin. A view will contain all of the markup, CSS, and etc. that you traditionally use with creating a static web page.
It’s what the user sees, and what the controller turns to the user. The controller simply forwards the user to the correct view, based on what they’re trying to do, but after they’ve received data from the model and forwarded this information to the view. The view then displays the information it’s given, in the format it’s structured with.
Sometimes seeing something makes it easier to understand. Below is a visual diagram of how the model-view-controller architecture works, starting from the user’s view (which would be a template, or view in MVC), sending the requested action through the architecture, and ending back at the view with the completed request.
The file structure for using MVC in the standard way is quite simple — there are simply folders for views, models, and controllers, and they all link to each other via one directory up. Of course, with any web application you’ll also have other folders and files, such as an index file (shown below), a folder for images, includes, and etc.
Below is a simple MVC directory structure with some example files. These follow my general naming conventions, and while each developer may have their own, it’s smart to have some standard naming convention of some sort. The files in the example structure below are merely examples, and developers may choose to structure or name their files slightly differently.
For More: Onextrapixel.com
A More Detailed Article At: Serversidemagazine.com