SoFunction
Updated on 2024-12-20

Django Project Layout Methodology (Recommended)

I. Advantages of this layout

  1. Each application in the project is relatively independent, making it easy to take it out and reuse it later.
  2. Such a layout will motivate you to consider the reusability of each application during development.
  3. Different environments such as development, testing, production, etc. have their own independent configuration files to facilitate the sharing and customization of configuration items.
  4. Each environment has its own separate pip requirements file.
  5. Each application has its own templates and static directories, and you can override the contents of each application with files from the templates and static directories at the project level.
  6. Tests for models, views, managers, etc. are saved in separate files that are easy to read and understand.

II. Layout generated by Django by default

Assuming the project is named foo, the default layout produced by using the python startproject foo command would be:

foo/
  
  foo/
    __init__.py

III. Recommended project layout

Assuming our project is called myproject, and there are two applications blog and users, the recommended project layout could be:

myproject/
  
  myproject/
    __init__.py
    
    
    settings/
      __init__.py
      
      
      
  blog/
    __init__.py
    
    
    
    
    templates/
      blog/
        
        
        
    static/
      css/
      js/
      …
    tests/
      __init__.py
      test_models.py
      test_managers.py
      test_views.py
  users/
    __init__.py
    
    
    
    templates/
      users/
        
        
        
    static/
      css/
      js/
      …
    tests/
      __init__.py
      test_models.py
      test_views.py
   static/
     css/
     js/
     …
   templates/
     
     
   requirements/

1. Directory location for each application

The top-level myproject directory contains the files and is therefore the root directory of the project. myproject/myproject/ is the project's content directory, where the project's root URL configuration file, and WSGI configuration file are stored.

myproject/blog/ and myproject/users/ are the project's two application directories. The advantage of placing the blog and users directories parallel to myproject/myproject/ instead of in myproject/myproject/ is that when you want to import modules from the application, for example, import models from the blog application, you can use import instead of import, which makes it easier to reuse the application independently. The benefit is that when you want to import modules in your application, such as models in the blog application, you can use import instead of import, which makes it easier to reuse the application independently.

2. Setting up individual configuration information for each environment

Create separate configuration files for each of the project environments, such as dev for local development, stage for internal testing, jenkins for automation, and prod for production.

  1. Create a new settings directory in the myproject/myproject directory and create an empty __init__.py in it.
  2. Move the myproject/myproject/ file to the myproject/myproject/settings/ directory and rename it to , the configuration information in this file is shared by all other environment configuration files.
  3. Create , , and 4 files in the myproject/myproject/settings/ directory, each containing the following line of code:
from base import *

In this way, these environment profiles will be able to read the default configuration entries, after which they can set customized configuration values in their respective profiles. For example, for the local development environment, you can add DEBUG=True**, and for the production environment ****, you can set DEBUG=False`.

Specifies which profile to use:

This can be specified through an operating system environment variable, for example:

export DJANGO_SETTINGS_MODELS=""

It can also be specified with a command line argument. for example:

./ migrate --settings=

or

gunicorn -w 4 -b 127.0.0.1:8001 --settings=

3. Modification of INSTALLED_APPS

The default INSTALLED_APPS will be.

INSTALLED_APPS = (
  ...
)

You can change the tuple () to a list []:

INSTALLED_APPS = [
  ...
]

It is further possible to separate third-party (built-in) apps in INSTALLED_APPS from our own, for example:

PREREQ_APPS = [
  ‘',
  ‘',
  …
  ‘debug_toolbar',
  ‘imagekit',
  ‘haystack',
]

PROJECT_APPS = [
  ‘homepage',
  ‘users',
  ‘blog',
]

INSTALLED_APPS = PREREQ_APPS + PROJECT_APPS

With this separation, we can do test and code coverage only for our own application.

The above changes to INSTALLED_APPS can also be made to TEMPLATE_DIRS and MIDDLEMARE_CLASSES.

4. Adjustment of pip requirements

Projects usually have a file that specifies the project's dependent packages. Based on this file, the following commands can be used to automatically install the dependent packages:

pip install -r

You can use -r filename in a file to include the contents of another file, similar to #include <> in C.

So, we can save the generic dependency information in the file myproject/requirements/, and for different environments, such as test environments, save it in another file, such as myproject/requirements/, where the contents might be:

-r 
pytest==2.5.2
coverage==3.7.1

5. Split test file

Create a directory tests in each application that contains the tests, and store the tests in separate files corresponding to different categories, such as test_models.py, test_views.py, etc. This way, the code is easier to read than putting all the tests in a single file. The advantage of this distribution over having all the test code in a single file is that the code is much easier to read, and it reduces the amount of time spent scrolling up and down in the editor.

6. URL configuration files

First, each application saves its own URL configuration, and then the URL configuration information of the sub-applications is included in the root URL configuration file of the project by using the include command:

urlpatterns = patterns(‘',
  url(r'^$', HomePageView.as_view(), name=‘home'),
  url(r'^blog/‘, include(‘')),
  url(r'^user/‘, include(‘')),
)

7. Templates and static documents

Each sub-application should have its own templates and static files directory, e.g. the templates and static files directories for blog should be located at: myproject/blog/templates/blog/ and myproject/blog/static/blog/. If you want to override templates and static files in a sub-application, you can do so by creating files with the same names in the root template and root static file directories of the project. For example, to override the templates in blog, you can override the default template files by creating the file myproject/templates/blog/.

8. Reuse of sub-applications

If you want to reuse the blog application in another project, the correct way to do it is:

  1. Extract the blog application to create a separate code base
  2. Install the blog application in each project using pip install
  3. In each project, use pip to update the dependent blogs

References:/blog/2014/nov/21/recommended-django-project-layout/

to this article on the Django project layout method (recommended) of the article is introduced to this, more related Django project layout method (recommended) content please search for my previous posts or continue to browse the following related articles I hope you will support me in the future more!