MVC or Model View Controller

MVC Stands for Model View Controller and it's software architecture design pattern. The main goal of this architecture is to separate functionality, logic, and the interface of an application to promote organized programming. It also allows multiple developers to work on the same project.

Let's take a look at different components of MVC from a web developer's point of view. Let's take a look at some of the popular web frameworks that use MVC.

• Ruby on Rails (Ruby)
• Express (JS)
• Backbone (JS)
• Angular (JS)
• Laravel (PHP)
• Zend (PHP)
• Codeigniter (PHP)
• Django (Python)
• Flask (Python)

Let's talk about Ruby on Rails and CodeIgnitor (PHP). These frameworks actually have folders in their file structure, called model, view, and controller. Something like Django for Python just borrows certain concepts but doesn't actually have that strict folder structure.

Another thing that can happen is one framework will put one aspect of the app in the controller and then another one is put it in the model, so I think that's why MVC is so confusing because there's not just one way to do — it there are actually many, many ways to create an MVC stucture.

Now, we are going to get into the three components of MVC: Model, View, and Controller.

Model

The Model is responsible for getting and manipulating the data, so it's basically the brain of the application. Usually, it interacts with some kind of database. This could be a relational database, like MySQL, or a NoSQL database like a MongoDB. It really doesn't matter and in many frameworks that support multiple databases, the model code will stay the exact same.

It's just the database driver that needs to change and it doesn't even have to be a database that works with it. It could be a simple file. So you could just have your model interact with a JSON file and pull data from that.

This it takes care of queries like select, insert, update, and delete, and the model also communicates with the controller. In most cases, the controller can request data through the model and, in most cases, the controller updates the view; but, with some frameworks, the model can actually update the view directly. This is another example of what makes MVC complicated.

So, just realize that there's different implementations and they can act differently from framework to framework.

View

Next, we have the view and you can probably guess what that takes care of. That's the actual view of the application, so it's the user interface, it's what the user sees and how they interact with the application.

So the view usually consists of HTML and CSS along with dynamic values from the controller. So the controller communicates with the view as well as the model. Now, depending on which framework you use, the template engine may vary.

The template engine is what allows dynamic data. If we have straight HTML, we can't output variables, we can't use logic, select an if statement, etc., but, with template engines, we can do that stuff right in the view or right in the template.

So, some examples of template engines would be Handlebars.js and Dust.js. Then, for Ruby on Rails, we have ERB, which is embedded. For Ruby, you can also use Haml and then with Python you have a Flask. There's a lot more of them out there and some do more than others, but you have a lot to choose from, especially with JavaScript.

Controller

So, finally, we have the controller and the controller takes in user input, so this could be from the user visiting a page or clicking a link which makes a get request or submitting a form which makes a post request and we also have delete requests or put requests for updating. And these can't be made directly from the browser, you can only do a get or a post but we do have HTTP clients that are at times built in with the framework, that can do that.

Now the controller acts as kind of a middleman between the model and the view. The controller will ask the model to get some data from a database and then the controller will take that data and load a view and pass that data into it. Then, from there, the template engine takes over and can basically do some logic, output variables, and things like that.

The controller can also load a view without passing it data, so just a plain web page with HTML and CSS, no actual templating logic.

Here's a very simple example or diagram.

Now we have the user, who sees the view of the application in the browser, and the app can make some kind of requests with input to what's called a router. And their request could be some kind of link that they clicked on some kind of route.

Then the router will call a specific controller method based on that route and if data is needed or if you need to fetch some data, the controller will then interact with the model, which interacts with the database. Then, once the controller gets that data passed back, it can then load a view and it can send the data to the view and it'll get dealt with by the template engine.

Once that's all done it'll send the view back to the browser for the user to see.

Conclusion

We can understand the MVC architectural pattern, as the model being the data, the controller being kind of the traffic controller, and the view being what the user sees and also interacts with. Hopefully you guys like this.