MVC architectural pattern - design patterns (ep 1)

till now we have learned about object-oriented programming concepts such as class object inheritance polymorphism then we learned about object oriented design principles solid principles then we saw how to draw class diagrams and now we will proceed to coding implementation programming implementation of all these concepts so we are going to do this programming implementation using design patterns so when we talk about implementation of object-oriented concepts we are going to need a language right so I think it goes without saying that let's use Java because Java suits our interest for our purpose the best but going ahead of that I would think that we should use framework rather than a language why should one use framework what is framework framework is nothing but a ready-made set of functions a ready-made set of functionality which could be ready-made set of classes set of files set of programs right they are given to you so it avoids repetition of code lot of boilerplate code such as database connectivity or rendering of views or you could say batch processing or sending emails or something like all these activities trivial activities when you talk about let's say web development or mobile development dessert driven activities connecting to database or sending emails so framework usually consists of classes which have this functionality so they save you the effort of writing this boilerplate code you don't have a write that code you just shut the focus you can just focus on your application logic so that is why it is always advisable to use framework instead of a language the second Vantage of using a framework instead of language is that it already implements most of the design patterns that we are going to study in the next set of videos so let's say you are one of those lazy programmers that you have learned object-oriented programming concepts solid principles even you have studied design patterns let's assume but when it comes to development you are not that vigilant well you're not that much enthusiastic about implementing all the patterns all the time so when a use of framework the advantage is that you don't have to do much the framework itself is already implementing most of these patterns directly or indirectly either behind the scenes or you can sometimes even see them in the code provided by framework so that is the beauty of it just by electing to use a framework you are already implementing most of the design patterns that we are going to talk about of course as your application logic demands you can also implement those patterns or principles while you could and that's what we are going to study but using framework also gives you that benefit when we talk about web development most of these frameworks implement a very popular pattern design pattern called as m-v-c canvas is not any other design pattern MVC could be called as pattern of patterns it's a compound pattern it's that it uses many other design patterns in itself that is MVC MVC stands for model view controller pattern let's take an example of any web application every wave application or for that matter actually even mobile application every application essentially will have three things those three things are it will have certain user interface right through which end-users will interact with your application it will certainly have some data which needs to be persisted in some kind of database and third it will have its business logic the algorithms the strategy of the application right so data is represented in your application in your MVC by models user interface is represented by views and controller is basically where you use your business logic although it's not that straightforward I mean business logic sometimes is kept partly in models partly in controllers and also you can write your own service classes which are used by controller so this business logic I would say it's always inside controllers right but general definition is data represented by models user interface represented by views and your business strategy or business decisions are usually made with philbo controller controller will be like a director of the movie he will get the task done either by the help of models some other service classes some external libraries or call it water in your web application client that is the end user has this browser where he says let's say www some obligation some application name slash home who is making a request for the home page of that application this request HTTP request is received by a controller right controller determines which view needs to be served to browser as a response to this request then the controller also for rendering that particular view what data is required so it contacts the model give the data from the model and creates that view finally sends back the HTML the markup the final view as a response to the browser so C controller is more like a coordinate between your model and your views right models primary job is to persist the data in some kind of database some kind of data store so models are usually classes which represent entities in your database that is called as suppose it is our DBMS then there are tables so there will be classes which represents models which represent these tables right so they will usually give you the functionalities that is create read update and delete on your data entities controller's job is to as I said act as a coordinator between model and use right now to further explain this phenomenon I take a simple example let's say let's take a simple example of user signup process right so in the browser right when you say signup for a particular application you go to the path of signup you see this form right username password email and some columns and then there is some button so now when you click this button controller receives this data the sign up form details right it creates it manipulates a model of user so there is some model of user controller uses this data to create instance of user model and model will create an entry in the database right for you with the data that controller passed to the model model we created instance of a user in the process let's say this model also generates a confirmation link for that user model will save this confirmation link back to controller why because now we need to send this confirmation link to that shown user let's say Y email right so what controller will do is that either controller or with the help of some service or library controller will get this confirmation link from the model generated current confirmation link and it will have some logic to send the link to the user either through email or some other medium right and after sending it the controller will update a view to the end user using a view that confirmation link is sent some message here new transformations link is straight wire email for example right so here there are two views first view so first you say I want to do sign on that request when two controller controller simply rendered you the empty form right once that form was filled and you said submit controller pass the data to model model create an instance of new user generated the confirmation link confirmation link was sent to controller controller send back a new view with displaying the information such as so basically controller first send that confirmation link wire email to the user and updated the view saying that a confirmation link has been sent to you on your email ID right this is no reason happening now how MVC is beneficial in this scheme let's say we want to change the view we want to change the UI design of the form you want to display this send confirmation link message in some other design right so I change these views the logic of it is present new files so I changed that using some CSS or some technology but that doesn't change anything in your controller and in your model models still generates the conformationally controller still sends the confirmation link wire email there's no change only view was changed because we wanted to change the UI so see they're very loosely coupled so change management is easier now take another example now let us say model over generating the confirmation link but it was really long like let's say about the link was above hundred characters now so we decided that models should generate a small confirmation link right so we change the logic in the model again is there any change needs to be done in controller no controller just gets that link and sends it over to the user or email view nothing you will just display the message confirmation link set so no change in controller or view when we change the model now let's say we want to send the confirmation link instead of email we want to send via SMS but we are taking the phone number the only thing that will change is the wave controller is sending the link it should have send email it is simple SMS but do we need to change the way model is generating the link no so controller will just make sure that the confirmation is link is sent to your phone so that slight change of message will happen in the view which controller will send to the browser so you see there very loosely coupled the views controllers and model they are doing their separate jobs independently of each other the benefit of which is one change management is easier as we saw when we change views we need not need to change controller model or when we change model we need not need to change controller views right another benefit usually no application when the project is complex and large designers and your developers we work on views without bothering about the business logic details or database model details so they will keep on working on views because user very loosely coupled and server-side programmers can work on your controllers and your models and for the service classes which are actually utilized by controllers or models both so there's a clear separation of work presentation layer can be worked by walked upon by UI designers you are developers whereas your server-side layer here also you can decouple it like database administrators or database developers can work on models and server-side programmers could work on controller and services so there is a good separation of division of work that is possible by using this MVC architecture in general most of the popular web development frameworks use MVC pattern some examples will be spring MVC laravel which is based on PHP asp.net MVC which uses Stesha then you have Ruby on Rails which uses Ruby and what we are going to use for the demonstration of our design principles coding we are going to use Grails Java based framework which uses a language called a screwy this is very similar to Java so all these frameworks use MVC design pattern for MVC architecture right in all of these frameworks you will find certain design certain directory structure certain artifacts which are common few of them there will be some configuration file so in every framework you will have some configuration file the name of the file will differ from framework to framework Spring has palm dot XML rails has some yml Grails has some application but why am L they will have different file names according to the framework and language but the configuration file will be there so this configuration file will have settings such as email settings from which account your web application will send emails database configuration settings if you are using memcache or caching mechanism or search engines those settings then you now directories for storing creating models directory for storing or creating controllers directories for generating view files then you know assets where you will have assets directory will have sub directories such as images style sheets JavaScript right and all those things and you have some directory for storing services services will have classes which will continue for the business logic services will be mostly utilized by your controllers or your models right so this is a general project structure that you will find in any MVC framework it does not matter very which framework in use the architecture is more important so missus comments so once you learn let us say this remote you can easily learn any of these other frameworks because they are all following this MVC architecture and Lara will will have these directories and these files and exactly same braces will also have these files and directories and any other project so it is the learning curve is very very less the learning curve is very less once you master any of the MVC frameworks because they all adhere to a certain architecture right now to round out the discussion I was just given a simple example I've told you in the beginning that when I had my attention of using this MVC architecture that it implements certain design pattern itself you don't have to worry about it one example is singleton design pattern you remember when you were in college and when you learn Java right you used to create that those edibility and swing based desktop applications using java the forms java forms AWT forms right and usually the college project would require us to connect those forms with some database say oracle right so you remember we used to establish JDBC connectivity using that JDBC connector class we used to create this corner object connection object with new JDBC and use the username and password and then on every of those forms right you should say connection that open and connection dot close right and in between you have to perform some SQL queries while the connection is opening before it closes then somebody told us that no instead you should extract out that connectivity code put it inside a class singleton pattern right create only one instance of that database connectivity class and just use this instance in all these forms pass it around the forms right that is one example of singleton pattern but when you use any of these frameworks right I said that you have to specify your data other settings in your configuration file like like you can see one here in the krills app config application not one file see so I am using this framework called as Grails as I said we are going to use Grails to demonstrate all the programming that we are going to do in order to implement our design patterns object-oriented design patterns so as I said in this application in this framework this application dot yml file where you specify your settings such as database and everything so I will show you see here so you specify your username password your database name in this case it will be sample app and driver name right now remember that we were supposed to implement this singleton pattern for database connectivity right create only one instance of the database connection and open and close it as anyway needed but the framework all these MVC frameworks that we are talking about they do it internally you don't need to worry about anything all I need to do is see here in I need to create a model class let's say forum and I just need to create let's say new forum object and as soon as I do it the framework creates the database connection object for me opens the connection does the fires SQL queries on the database and closes the connection so the singleton pattern is definitely implemented but I don't need to do anything the framework is doing it for me so that's the added advantage of using any framework for development itself implements lot of patterns while in its structure the way it takes care of the boilerplate code for you now one more thing I wanted you guys to see is that the directory structure of this general framework so as I said there's a assets folder where you will have your images your java scripts your style sheets right stylish it will generally be CSS JavaScript and your images icons and everything then you will have your configuration folder so this file has all the configuration of email a basis and everything then you will have folder for controllers where you will have all your controllers right one one specific type of controller is called as a router in this framework it is called as your mapper so where you specify your routes so your home route that is which fires up your application you know like www.hyken.com will be solved by main controllers index method so I'll come to this in detail when you talk about our programming examples in this framework there following it as domain but this is your model folder where you will store all your models where you will create all your models basically right then you will have views folder where you will create all your view files generally these are they create the contain HTM markup yeah and along with that they'll have some server-side code so here it is GSP in Grails that is crew B server pages in spring there will be JSP javaserver pages in rails they will be HTML or ER be embedded Ruby and then in PHP PHP HTML not player or something like that and in asp.net there will be something else oh but they're so identical that all the views will be HTML plus some server tags some server server little bit of snippets of server-side code yeah so it's very common in all these frameworks so the point of showing you this grid tree structure is that no matter which framework you choose be laravel rails asp.net or spring or grains will have similar kind of directory structure for you similar kind of folders similar kind of files yeah they will have certain changes of syntax here and there but conceptually they remain the same and yeah they're just great to you and in next video we start discussing object-oriented design patterns we start with our first pattern in the next video and I'll explain the pattern first on my whiteboard and then we'll see how to implement it programmatically using our today's complex problem statement right so I'm looking forward to discussing this object-oriented design patterns with you

Channel: BBarters

Views: 52,919

Keywords: mvc, mvc pattern, fundamentals of mvc, model view controller, grails, grails mvc, oop design patterns, basics of mvc

Id: e9S90R-Y24Q

Length: 24min 58sec (1498 seconds)

Published: Wed Aug 02 2017