MVC – Model, View, Controller
MVC is a relatively abstract “ideal” and plan to help design user interfaces. But it’s downright confusing.
MVC is a “software architectural pattern”… duh what? In more simple terms, it’s a concept and pattern on how you should design your website. It’s a concept that helps you organize your code more cleanly and with more of a meaningful use (Health IT is leaking!) Granted this is just a recent concept to me, but the idea was so perplexing to me that I wanted to research more into it and share to my open and beautiful internet, just what I learned!
Although it can be applied to many applications, I’m primarily going to talk about in the web development field. Historically, it was a concept that was meant to help develop GUIs, but it has since been popular in designing web applications. In web applications, MVC responsibilities are divided between the client and the server. Client can either send requests or form input to the controller, and then receives an updated web page from the view, where the model is located on the server. Thought recent years have led to newer frameworks that execute some of the MVC components on the client.
The model is typically a variety of objects that represent the data from the database/server as well as the functions to push and pull that data. The data can come from anywhere, not just the database. Should not be concerned with request.
The controller handles the request logic, as well as any manipulation of models. As a result, the controller should do any instantiation of models. It is the request/response logic that satisfies the client’s request. Can also send it to different controllers for different requests. It also takes the job of normalizing the data so that it can be stored in the model, it should not worry about how data is being modified.
Lastly, the view is the HTML file or displayed page, on the caveat that it only displays as much code in them as is required to show the data. This is the display portion, while controller was kind of the logic. View should never concern itself with either.
Although developing and organizing the code like this can be more tedious and tiresome, it is meant to help make complex or larger projects easier to maintain over time. Of course, if it is a simple project, the work may be more costly than the payoff. It helps divide the content, design, and behavior and separates it from the logic and output. It helps manage back-end coding, front-end displaying, and front-end requesting as necessary.
A perfect example of this in an ELI5 Manner:
You’re in a shoe shop – the shop is the view, the stockroom (with boxes of shoes) is the model and the salesperson (who goes into the back to find your size) is the controller.