Django's MVT-Relationship between Models and Modules-

Purpose

Let's summarize the MVT patterns when using Django and the modules corresponding to each pattern. By the way, a module is a source file of "~ .py". A package is a folder for managing source files. (OK if you think of it as a Python dialect)

background

I often hear MVT patterns, and I often see articles about Django frameworks. However, I thought it was difficult to imagine the correspondence between the two, so I will summarize it as a memorandum. Please comment if you want to write in more detail or if there is something wrong.

What is the MVT pattern?

Description
Model Data management
View Call control
Template User interface

Is it like this if you write it simply? In addition, there is a function that can use the input data control class called Django form, and if you make a large-scale application, you can think about the architecture a little more and separate the service layer and the domain layer, but that is I will try to summarize it in a detailed version someday.

First, configure the Django project

For example, I will introduce the basic configuration when creating a project called "sample_project" and creating an application called "sample_app" in it. (For folders and modules that aren't created by default when you create a Django project and you need to add them yourself, add a star in front of their names.) (For packages or folders, add * after the name)

sample_project*
  | - sample_project*
       | - settings.py
       | - urls.py
       | - wsgi.py
  | - sample_app*
       | - migrations*
       | - ☆templates*
             | - ☆static*
             | - ☆sample_app*
       | - models.py
       | - views.py
       | - ☆urls.py
  | - manage.py

Since the focus of this article is MVT, we will omit unrelated packages and modules.

Which module corresponds to each layer?

We will actually introduce the modules that correspond to each layer. Model This is related to Model

sample_project*
  | - sample_project*
       | - settings.py ・ ・ ・ A
  | - sample_app*
       | - migrations*・ ・ ・ B
       | - models.py ・ ・ ・ C

** A. Project-wide configuration module ** It is not a module used only by Model, but database setting information etc. are written here.

** B.migrations package ** Contains the source files generated by the make migrations command when you try to build a database in your code base. The migrate command applies the contents here to the database.

** C. Module for defining each Model class ** You will define your own Model class here. How to create Model class

View This is related to View It is important to remember that View requires not only the definition of the View function for post-call control, but also the setting of the URL dispatcher as to which View function to call.

sample_project*
  | - sample_project*
       | - urls.py ・ ・ ・ A
  | - sample_app*
       | - views.py ・ ・ ・ B
       | - ☆urls.py ・ ・ ・ C

** A. urls.py ** in the project package Describes the dispatcher information for calling the View function based on the URL. However, this module describes a URL dispatcher to split each application in your Django project. In this example, like http: // ~~~~~ / sample_project / sample_app / Register the URL dispatcher up to the division of the application after the host name.

** B. Module for defining each View function ** Define your own View function here.

** C. urls.py ** in the application package Contains information about each URL dispatcher in your application. You will need to add this module yourself. You will be registering a URL dispatcher that is a continuation of the URL divided for each application by the above * A. *. In this example, you can specify a URL like http: // ~~~~~ / sample_project / sample_app / home or http: // ~~~~~ / sample_project / sample_app / edit. Register the part after / `.

Template This is related to Template

sample_project*
  | - sample_app*
       | - ☆templates*
             | - ☆static*・ ・ ・ A
             | - ☆sample_app*・ ・ ・ B

** A. Rendering file (css file or JS file) storage package ** In addition to HTML, files necessary for screen configuration are placed here.

** B.Template file storage package ** Place the HTML file here.

Summary

If you use a framework, it's quite important to organize where and what to write! This time, I've focused on the folders and files that you have to look at here for each MVT with a simple structure.

Recommended Posts

Django's MVT-Relationship between Models and Modules-
Differences between Django's request.POST ['hoge'] and request.POST.get ('hoge')
Python packages and modules
Between parametric and nonparametric
Difference between process and job
Correspondence between pandas and SQL
Conversion between unixtime and datetime
Difference between "categorical_crossentropy" and "sparse_categorical_crossentropy"
Understand Python packages and modules
Difference between regression and classification
Collaboration between PTVS and Anaconda
About Django's deconstruct and deconstructible
Connection between flask and sqlite3
Difference between np.array and np.arange
Difference between MicroPython and CPython
Create and list Django models
Cooperation between py2exe and setuptools
Boundary between C and Golang
Difference between ps a and ps -a
Difference between return and print-Python
Comparison of time series data predictions between SARIMA and Prophet models