Why MVC
What is it and what problem is it solving?
MVC - if you have been any organized software you will have at least heard of it, or of software architectural patterns in general. The goal of any architectural pattern is to improve maintainability, ease of debugging, and generally make a codebase easier to work with.
MVC stands for Model, View, and Controller - the three primary concerns to split up an application into. While this is going to be themed around JavaScript-based Fullstack Web Applications, MVC was actually created in the late 1970s, being applied to GUI & CLI applications.
Originally it was actually Thing Model View and Editor, where Thing represented user interests, and View had the interactability split off into Editor.
But Why?
Imagine a web application that allowed for simple authentication and then CRUD operations to be done to Todo items associated with each user.
Without any best practices such as data validation or anything this can expand to over 100 lines, now imagine there was an issue with logging out, just as another team member was adding a last updated field to the Todo entries. If you're lucky the two developers will not touch the same lines of code, but you won't be, resulting in a merge conflict when the changes all get merged back to production.
Or imagine the authentication stopped worked at some point, so the middleware would need inspection - it could be any of the middlewares to blame, they would have to be gone through one by one.
The application becomes popular and a migration to a better data source is needed, good luck doing anything else because this change would effect nearly every aspect of the application, resulting in any work that was also done during this migration to be partly rewritten.
Maybe someone wants to ensure some complex interaction is working as expected via a test - well they'll have to get tne entire application flow working and tested before they get to the functionality they actually want to test.
These and many more are the problems that MVC aims to solve.
It allows responsibilities of the application to be divided up as such:
- Model
- Managing data, from structuring it in a way for the rest of the application to use, to making direct changes
- View
- Presenting the data to the user, and allowing the user to interact with the data
- Controller
- Responds to the user, performing the desired logic based on the interaction, directly communicating to the Model and View
In a perfect MVC implementation, swapping our the Model or View for an entirely different implementation results in little to no needed changes in the other two concerns.
MVC
Model
Anything that has to deal with the data, exposes a consistent interface for the controller to do whatever is needed, yet abstracts details the controller doesn't need away from it.
This can be a collection of functions that makes direct requests to the data source, to an O(R/D)M, allowing the entities to be interacted with in an OOP manner.
Most ORM/ODM - Object Relational Managers and Object Document Managers - libraries take advantage of a defined schema, a structure that documents the expected shape and types of each piece of data, from field/column name & types, to - depending on the library - custom validation checks for each piece of data.
For NoSQL databases there are a few ODMs:
- Mongoose, Prisma, TypeORM
...and for SQL databases you have similar ORMs:
- Sequelize, Prisma, TypeORM, Waterline
View
What users directly interact with, be that a CLI, GUI, or in this example a Webpage - collection of HTML, CSS, and sometimes JavaScript.
The view is all of this, for server-rendered applications it's specifically the HTML, and for client-rendered ones it's a combination of the HTML & the data fetched by client-side JavaScript which is eventually rendered into HTML.
Various libraries can serve as view engines - generator of views for the user - from pure HTML, templating engine such as EJS, Handlebars, Pug, to frontend frameworks such as React, Vue, Angular!
These all serve the same purpose: present received data to the user, and allow the user to interact with the application & data.
Controller
What brings the View and Model together, it's the first code ran by the user - from the starting of the application to the visiting of the homepage - the controller is the code that takes in user requests and obtains the needed data via the Models, passes it to the Views, and subsequently ensures the user is delivered the View.
It then responds to every request the user has, and performs the unique logic to respond to each.
Unlike the other two, while there do exist some libraries that help with controller logic, for the most part it's done manually or the current web framework - Express for example - provides all that's needed for controller logic implementation.
Router
Sometimes you'll see the controller logic split up further, with the routing of user requests being moved into Routers. This allows controllers to be the pure logic of what to do when requests are received, instead of what requests to respond to and what to do when those requests are received.
Not only does this improve the purity of the controller, but it additionally allows routing to be independently customized.
Scalability
Each of these responsibilities can be further divided, usually by topic - such as a Model, View, Controller, and Router specifically for authentication, and another Model, View, Controller, and Router for Todo items.
