Programming is hard, building complex applications is really hard and building complex applications that can scale and stay resilient, easy to update and work with is really why programmers are so important. The MVC (Model. View. Controller) architecture is a software architecture pattern that breaks up any application into 3 separate but more manageable parts; the Model, the View and the Controller.

PS: I use very obscure but visual examples in a lot of my writing because I am very stupid and very visual examples help me learn gud.

To explain MVC, Imagine a book library where you could request any book or story and get a private improv theater show produced for you telling you the story or about the book. Imagine you walking into this library and being assisted by a host/hostess who’s only job is to be personable and be your guide (but one who knows nothing about the show or library books).

Lets say you request a show on Hamlet, the host/hostess would first have to go to the librarians with your request (because they are not allowed anywhere near the books) then after getting the book (in this case hamlet) they would then give it to the theater department and lead you to the theater where you would get to see the improv show.

• Library = your application.
• Host = Controller
• Librarians = the Model.
• Theatre department = the View.
• The book Hamlet = The data you requested.

I hope that made sense to some degree but to put it in a more conventional context, applying MVC to any project is a separation of concerns convention where:

1. Having a Controller that handles the request flow, from routing, requesting data from the model to leading the user to their requested resource/ screen. The controller itself never directly interacts with the data/ database or how it’s displayed, it simply couriers the user’s request to the Model and after getting the data passes it to the View to handle the presentation of that data.
2. Having a Model that queries the database, handles authorization (when adhering strictly to the MVC architectural pattern) and structures the data accordingly.
3. Having a sperate View that handles the data received from the controller (via the model but never directly from the model) and decides how to present UI based on that data.

Hope that my explanation helps in explaining what the M, the V and the C in the MVC software architectural pattern.