over the last 20 years websites have gone from simple HTML pages with a bit of CSS to incredibly complex applications with thousands of developers working on them to make working with these complex web applications much easier developers use different patterns to lay out their projects to make the code less complex and easier to work with by far the most popular of these patterns is MVC also known as model view controller the goal of this pattern is to split a large application into specific sections that all have their own purpose to illustrate each section let's look at an example where a user is requesting a specific page from a server based on what URL the user is requesting the server will send all the request information to a specific controller this controller is responsible for handling the entire request from the client and will tell the rest of the server what to do with the request it acts as a middleman between the other two sections model and View and should not contain very much code the first first thing that happens when a controller receives a request is it asks the model for information based on the request the model is responsible for handling all of the data logic of a request this means that the model interacts with the database and handles all validation saving updating deleting and Etc of the data the controller should never directly interact with the data logic and should only ever use the model to perform these interactions this means that the controller never has to worry about how to handle the data that it sends and receives and instead only needs to tell the model what to do and respond based on what the model returns this also means the model never has to worry about handling user request and what to do on failure or success all of that is handled by the controller and the model only cares about interacting with the data after the model sends its response back to the controller the controller then needs to interact with the view to render the data to the user the view is only concerned with how to present the information that the controller sends it this means the view will be a template file that dynamically renders HTML based on the data the controller sends it the view does not worry about how to handle the final presentation of the data but instead only cares about how to present it the view will send its final presentation back to the controller and the controller will handle sending that presentation back to the user the important thing to note about this design is that the model and view never interact with each other any interactions between the model and the view are done through the controller having the controller between the model and the view means that the presentation of data and the logic of data are completely separated which makes creating complex applications much easier this is all just theoretical though so let's look at an example of how this design handles a request imagine a user sends a request to a server to get a list of cats the server would send that request to the controller that handles cats that controller would then ask the model that handles cats to return a list of all cats the model would query the database for a list of all cats and then return that list back to the controller if the response back from the model was successful then the controller would ask the view associated with cats to return a presentation of the list of cats this view would take the list of cats from the controller and render the list into HTML that can be used by the browser the controller would then take that presentation and return it back to the user thus ending the request if earlier the model returned an error in instead of a list of cats the controller would handle that error by asking the view that handles errors to render a presentation for that error that error presentation would then be returned to the user instead of the cat list presentation as we can see from that example the model handles all of the data The View handles all of the presentation and the controller just tells the model and view what to do and that's all there is to the basic architecture of MVC in the next video we're going to be doing all of the basic setup for our library application and deploy into Hoku so make sure to check out that video linked over here when it comes out also don't forget to subscribe to the channel to do not miss any more videos in this series thank you very much for watching and have a good day