MVC Pattern Explained Easy | MVC Tutorial (Example in NodeJS)

hey guys how's it going i'm back here with another video and today i decided to bring this video which i'm very excited for because a lot of you guys have been requesting in the past for me to make a video explaining how the mvc architecture work or just explaining how you can organize your apis in a better way and for that reason i am excited to bring this video where i'm going to go over the mvc pattern and just overall like talk about how you can organize your api how can you organize your the structure of your project so that you're building a consistent service that people can actually look at the code and say well this is like that this is well written code and before we get into the tutorial if you guys could leave a like and subscribe if you're not subscribed i would massively appreciate it uh it will help push my videos to more people so i would be very happy if you guys did so and yeah that's basically it let's get into the tutorial well the first thing i really want to talk about is what exactly is mvc and um this is a point that a lot of people don't like understand very well and they already try to learn how to implement mvc into their project without actually knowing why mvc is used or how it is used and for that reason i want to explain to you guys just a little bit about what the pattern does and how it will be approached when you're actually coding so mvc stands for model view controller and some cases it will be kind of changed because um this will be very applicable for cases where you're you're talking about the whole application that's where the view part comes from however i want to i want to create this very specifically for an api because it is very confusing to uh try to think of your application as a full stack application it is better to actually focus on both the front end and the back end separately so that you actually have some time to understand what is happening on each side so if we're talking about the back end individually we would see the model view controller as just a way to communicate between different services inside your application by dividing it into three different components so for example you can see that we have a user right and this user makes a request to an api so when this user makes this http request to the api it would probably make a request to an endpoint and what would happen in the backend is they would get this end point the end point you're defining the backend in which the user is making the request would recognize that a request has been made then it would call a function which is called the controller and the controller would call another service which would return the data that the the user wants then the controller would get that data do whatever it wants with that data and then return back to the user so the whole idea is if you have an api endpoint usually what goes on in an endpoint is you usually get some information from the user from about what you want to do then you call some sort of database then you do something with the data you get back from the database and then you return something to the user that's kind of the flow right however by using mvc you're kind of dividing your project into three different parts or it doesn't need to be three but um you can divide it into various different parts various different services and each of them communicate so that you're basically separating your logic throughout your your actual project and it will make a lot more sense as we go into i'll actually provide an example for you guys that is very well designed so that you guys can understand it better but for now just know that it is as simply as possible just a way to divide all of the logic into different components and as i mentioned before this is kind of a realistic flow of how um how the an mvc project might go um i want to acknowledge that there is actually no standard way of calling your services or calling the folders in your project or actually calling the components in its own um obviously people call the controller the controller some people call them the models the models how i like to actually do it is i define my project into three folders and those folders are the different services that our api will be divided into those services include the controller the service and the routes i also include the models which is basically depending on which kind of database system you're working with which kind of project you're working with but it's just a way to define the structure of your your actual data and obviously it's not applicable for everyone and it will make a lot more sense as we go into this but i just want you guys to know that in reality what would basically happen is this user over here would make an api call which would then make a request to an endpoint that endpoint would recognize the request and then call the controller which would then recognize what the user wants because the user will pass data to this control to this endpoint which would then pass data to this controller and then the controller based on what the user passed would call some sort of service which deals with the database then that service will return whatever the controller wanted which would then do something with the data maybe manipulate it maybe i don't know just return it and at the end the endpoint would return back to the user whatever the user requested it is very well distributed the logic so that um you'll never have repeated logic and you can actually reuse some of the components throughout your application as i mentioned i like to use a specific folder structure which it's obviously not standard like there's no standard for the for how you should structure your project using mvc but here is a very common way of doing it basically i would have folders throughout my api and those folders would be the routes folder which would define the endpoints the models folder which would define the the database tables so like if you're using mongodb for example it would be where you would define your schemas if you're using i don't know sql i like to use arms which you need to define the models or define your your tables so here's where i would put that and then we would have the controllers which would be where we would hold the functions which calls the service and deals with the data so the controller will call the the the functions in the service folder the stuff in the service folder will return back the data to the controller and the controller would manipulate that data and do whatever it was with it and give it back to the user so this is kind of how the folder structure would go and i will show you guys a very very simple example by using an express api to explain it to you guys now it doesn't really matter if you guys are not experienced with node.js javascript and express this will be very similar in many different languages i've worked with apis in different languages before i've worked with creating an nvc api using java i've worked with creating a similar pattern using go so i'll just tell you something you don't need to really worry about which language you're using or how specific you need to be just know that this pattern can be seen in many different languages and the way i'm structuring my api in this video it is very similar but if not the same as how you would with another language the only difference is obviously the syntax because you can't like replicate syntax in different languages so i'll just show you guys an example and try to go through it just so you guys can have a better look at how it actually works okay everyone so as you can see right here we have i open vs code and we have a very very simple example of how an express api might run again if you're not familiar with express or node don't worry about it all we have here is a folder called routes which has all the endpoints we want and we divide each endpoint by the kind of table or the kind of data we're trying to manipulate so for example if we have a table called users then we would probably create a user route which includes all the routes and endpoints that manipulate or deal with the user in itself so if you're used to express you know what this means right i have some get requests over here this is a get request which gets a list of users all the users in the table this is a get request which gets a specific user by id then we have a post request which creates a user and obviously whatever's written inside of here doesn't really matter actually this i don't even know what this is like i'm not using any database over here this is just a an example for you guys but you get the idea right we're putting all of the logic in an api into a single file which is our routes file and inside of here we're doing everything we are dealing with what the user sends for example here where we try to get a user by id the user sent an id through the params so we're we're dealing with this over here we're also dealing with uh calling the database directly so we're making a request to our database and we're also dealing with manipulating the data or returning the data which is a lot of stuff for a single function or a single file and that's why it becomes not maintainable because if you have thousands or hundreds of endpoints and you have a lot of stuff dealing with the table or you have a lot of stuff that can be reused um then you will you will find it so that it is not very maintainable to keep your api structured this way and it might be annoying in the beginning to switch from what you've been used to before and how and what is a lot simpler to something that seems redundant in the beginning like following a specific architecture or a specific pattern however believe me in the long run it definitely helps it gets you to understand how um to i structure your code better and in the real world you won't ever find some sort of api actually written like this you will always find some sort of structure and design pattern that is used in every single project because it is the only way to maintain a project that is that has thousands of lines of code so now that we've seen um the simple example of how you should instructor api and how you actually shook your api without mvc let's start looking at how you would with mvc so as you can see over here we have our mvc folder structure already designed and as you can see as i showed actually in the slides previously it is divided into four folders but you can definitely add more folders there's no actual fixed pattern to this but these are the main folders that we're going to be using in any mvc application and basically as i mentioned the models folder would hold any definition of schema or definition of tables for my database right i don't have anything actually here because this is an example project but then we have our routes folder and as just as an example i created two routes uh two routes that we might have in an application so imagine we're building a website which has a table called users and has a table called book and in the user route we would have um everything related to the user individually so for example we would have a get request which returns a list of all the users in the table a get request that might return a user by specific id or maybe a bud request which updates a user or a delete request which deletes a user with a specific id the important thing to notice that is different from this kind of pattern from the previous one is that we are actually not defining the function in the routes folder we're actually defining our route and whatever endpoint um or whatever like name in the endpoint it needs and then we're calling this thing called get all users or get user or update user or delete user which actually functions from the controller folder so in the controller folder for each route in our routes folder we would probably have a a similar file with the same name in our controller folder and over here as you can see we have all the functions that are called whenever there is an endpoint in the routes folder so this is kind of how it would go you would have a definition of your route and you would have a folder which contains the functions that are called when that route or that request is made so for example for the get all users we have here this function called get our users which should in theory return at the end the list of users right but if you recall how i explained the controller i mentioned that it would make a call to the table service or to the service which communicates with the database um and then at the end manipulate the data and return it which is kind of what we're doing over here you can see we have this very specific and very weird functions called query list of users or query user by id or for the delete we have delete user by id and you might think that they are already built in functions but they're actually functions that i created and this is where the service folder comes you would get every function or every query or every like whatever thing you want to do to your database to your tables and create specific functions for them in the user table file so over here in our service folder we would hold all of the files that include manipulating and making queries to our table so you can see that we created this function called query user by id and all it does is it queries the you it requires an id and it returns some user from the table from the user table um that has that specific id and this can be reused now everywhere in our application that we might want to query some user by id but now we can just access the user table file and just access this function directly we don't need to rewrite rewrite we don't need to rewrite the logic on our own because we can just do it like this and we also create other functions that we might want to use like this one over here and we can even specify some stuff like if we want to specify some sort of condition for which kind of users we want to get from our table we can pass it over here and write some sort of logic to decide on what we're doing but at the end of the day the important thing is every function over here should be communicating with our table directly and returning the data that it gets or the information that it gets from our database back to the controller and now in the controller we would get that data as you can see over here we get the result of the the user table query list of users function um and we do something with it in our case over here we're not we're not doing anything with it but we can this is where you should write the logic for mutating or updating or doing something with the data that you got from your table as you can see we don't do anything but the important part of the controller is that at the end we return the response as a json um back to the route and in the route is where we would return this back to the user who made the request so that the user gets the data that he wanted and this is kind of the flow right and it kind of makes sense after you try and after you try making like one or two endpoints you kind of get the gist of it you have an end point which calls a controller which has a function specific for that endpoint this controller calls a function in the service folder which deals with the database which deals with what you want to do with the database or the table and then it does something with the data that you return that you try to get and at the end it should return a response to the user so that the user gets a response to its request now the flow it's kind of weird in the beginning but um if you definitely try out a structure like this you'll definitely get the gist of it i'll be posting this i'll be pushing this structure to my github so you can get an idea of how it's working i will actually make it work as a simple express api um which will actually work it won't be like this which is completely fake data or this isn't even a database that i'm using it will actually be an example that works very simple just so you guys can clone it or download it on your own and play around with it just to understand how the pattern actually works however this is basically it for how to use mvc for creating and structuring an api if you have any doubts leave a comment down below i'll be responding to most of the comments um i'm really interested in nowadays and how to design your project structure and i know it's kind of annoying um for a lot of people because it kind of slows down development in the short term however believe me if you're trying to build a large application by just storing everything in a single file and not following some sort of principle or some sort of design pattern you're gonna surfer you're gonna suffer in the long run so this is basically it if you enjoyed it please leave a like down below and comment what you want to see next subscribe because i'm posting two to three times a week and i would massively appreciate if you guys could help out the channel grow help us i don't know reach our next milestone right now that would be 20k subscribers and i would be very happy if we reach that and yeah that's that's basically it i really hope you guys enjoyed it and i see you guys next time

Channel: PedroTech

Views: 2,337

Rating: 4.9550562 out of 5

Keywords: computer science, crud, css, databases, javascript, learn reactjs, mysql, nodejs, programming, react tutorial, reactjs, reactjs beginner, reactjs tutorial, typescript, react js crash course, react js, node js, express js, pedrotech, traversy media, traversymedia, clever programmer, tech with tim, freecodecamp, deved, pedro tech, mvc, model view, model view controller, mvc tutorial, mvc nodejs, mvc express, mvc api tutorial, mvc pattern, nodejs folder structure, mvc architecture

Id: bQuBlR0T5cc

Length: 17min 5sec (1025 seconds)

Published: Mon Jul 26 2021