26
loading...
MVT Architecture: part-2.1
I mentioned about the MVT (Model-View-Template) architecture earlier.
You must be knowing the MVC architecture that allows developers to change the visual part of an app and the business logic part separately, without affecting one another. But it's a little different in case of Django.
Django forces the developers to separate their development of application into 3 loosely coupled components, the model, the view and the template.
MODEL : Data Management Layer
It is the component that manages an application's data and usually interacts directly with the database (PostgreSQL in our case).
It is the component that manages an application's data and usually interacts directly with the database (PostgreSQL in our case).
TEMPLATE : Data Presentation Layer
This is the layer that presents data to or accepts data from the user, (usually this is what most users interact with).
This is the layer that presents data to or accepts data from the user, (usually this is what most users interact with).
VIEW : Between Layer
This is the part that sits between the data management layer and the data presentation layer. (This layer grabs data, usually, some user input, from the presentation layer, manipulates the data, and then passes it to the data management layer or vice-versa).
This is the part that sits between the data management layer and the data presentation layer. (This layer grabs data, usually, some user input, from the presentation layer, manipulates the data, and then passes it to the data management layer or vice-versa).
I can give you a couple of example for the better understanding of the MVT architecture...
Example 1:
1) Customer makes a request for the menu page.
2) Django maps the incoming request (URL) to the application logic (view function).
3) A list of URLs will be specified in the URL configuration file.
4) Django looks into the list of URLs and invokes the appropriate view function mapped to URL pattern where the match is found.
5) And then, the requested menu page will be rendered from the templates to the customer, through the browser.
Example 1:
1) Customer makes a request for the menu page.
2) Django maps the incoming request (URL) to the application logic (view function).
3) A list of URLs will be specified in the URL configuration file.
4) Django looks into the list of URLs and invokes the appropriate view function mapped to URL pattern where the match is found.
5) And then, the requested menu page will be rendered from the templates to the customer, through the browser.
Example 2
1) We can have another scenario where a new customer is trying to register by sending some information. Now here, this becomes a save request from the user.
2) This save request goes to the models file where a set of python classes are defined that maps the database table to the python objects.
3) Models file directly interacts with the database through the database API, psycopg2.
1) We can have another scenario where a new customer is trying to register by sending some information. Now here, this becomes a save request from the user.
2) This save request goes to the models file where a set of python classes are defined that maps the database table to the python objects.
3) Models file directly interacts with the database through the database API, psycopg2.
This was a brief explanation of the MVT architecture.
26