ジャンゴシリーズ Django プロジェクトの構造と構成の分析

著者: Li Juncai (jcLee95) : https://blog.csdn.net/qq_28550263
電子メール : [email protected]
記事アドレス: https://blog.csdn.net/qq_28550263/article/details/132893616

【介绍】：本文讲解Django的项目结构与配置。

前のセクション: 「Django 開発環境の構成と最初の Django プロジェクト (プロジェクト)」 | 次のセクション: 「Django アプリケーション (アプリ) の作成と構成」

1。概要

この記事では、Django プロジェクトの全体構造を紹介します。これは、各ファイルとディレクトリの役割、Django プロジェクトの設定ファイル (settings.py) でそれらを指定する方法など、Django プロジェクトの基本的な構造にすぎません。初期Djangoを網羅的に紹介プロジェクト内のsettings.pyファイルの各設定項目の機能と設定方法。

2. Django プロジェクトの構造

Django プロジェクト構造とは、典型的な Django プロジェクトに含まれるディレクトリとファイルの構成を指します。この構造は、プロジェクトのコードとリソースを整理するための明確で保守可能かつスケーラブルな方法を提供するように設計されています。

2.1 プロジェクトのルート

プロジェクトの最上位ディレクトリ。通常はプロジェクトの名前です。このディレクトリには、プロジェクトの構成ファイル、トップレベルのアプリケーション、静的ファイル、テンプレートなどが含まれます。

manage.py: プロジェクト管理ツール Django のエントリーファイルで、各種管理コマンドを実行するために使用されます。
myproject/(プロジェクト名): プロジェクトの Python パッケージ。プロジェクトのメインディレクトリでもあります。
requirements.txt: プロジェクトに必要なすべての Python パッケージのリストを表示します。通常はを使用してインストールされますpip。

たとえば、データベース移行 (マイグレート) がコンソールに出力されたプロジェクトのファイルディレクトリ構造は次のとおりです。

myproject
├── myproject
│   ├── __init__.py    # 用于将 myproject 目录标识为 Python 包
│   ├── asgi.py        # ASGI 应用程序入口点，用于支持异步 Web 服务器
│   ├── settings.py    # 项目的主要设置文件，包括数据库配置、应用程序设置等。
│   ├── urls.py        # URL 路由配置文件，定义了 URL 映射到视图函数的规则。
│   └── wsgi.py        # 用于生产环境部署的 WSGI 应用程序入口点。
├── db.sqlite3         # SQLite 数据库文件，项目中的默认数据库。
└── manage.py          # Django 项目管理工具，用于执行各种管理命令，如启动开发服务器、创建数据库迁移等。

注: 通常、現在の Django プロジェクトに必要な依存関係は仮想環境にインストールされます。開発が完了したら、システム Python で使用されるパッケージではなく、このプロジェクトで使用されるパッケージを仮想環境にエクスポートします。次のコマンドを使用して、pip がインストールされたファイルをエクスポートし、次のrequirements.txt名前のテキストを書き込むことができます。
pip freeze > \path\to\requirements.txt       # 替换为你想保存requirements.txt文件的位置
このテキストの依存関係を新しい環境で一度に復元する必要がある場合は、次のコマンドを実行できます。
pip install -r requirements.txt
Django プロジェクトだけでなく、他の Python プロジェクトもこの方法で移行できます。

2.2 アプリケーションカタログ（アプリ）

Django プロジェクトには複数のアプリケーションを含めることができ、各アプリケーションはプロジェクト内の特定の関数またはモジュールの処理を担当します。各アプリケーションには独自のディレクトリ構造があり、通常は次のものが含まれます。

models.py: データベーステーブルの構造とフィールドを含むアプリケーションデータモデルを定義します。
views.py: アプリケーションのビュー関数を定義し、HTTP リクエストを処理し、HTTP レスポンスを生成します。
urls.py: アプリケーションの URL マッピングルールを定義して、URL リクエストをビュー関数に関連付けます。
templates/: アプリケーションの HTML テンプレートファイルを保存し、ページコンテンツの生成に使用されます。
static/: CSS、JavaScript、画像などのアプリケーションの静的ファイルを保存します。
その他のカスタムモジュールとリソースファイル。

2.3 設定ファイル

Django プロジェクトの構成ファイルは通常、プロジェクトのルートディレクトリ内の同じ名前のサブディレクトリにあり、settings.pyデータベース接続、静的ファイルパス、国際化設定など、プロジェクトのさまざまな設定を構成するために使用されます。

2.4 データベース移行ディレクトリ

データベーススキーマの変更を管理するために使用される、データベース移行用のファイルが含まれています。データモデルを変更するたびに、Django は新しい移行ファイルを自動的に生成し、makemigrationsおよびmigrateコマンドを使用して変更を適用できます。

2.5 静的ファイルディレクトリ

Django の静的ファイルディレクトリは、CSS スタイルシート、JavaScript スクリプト、画像、フォントなど、プロジェクトで使用される静的ファイルを保存するために使用されます。これらの静的ファイルには通常、動的コンテンツは含まれませんが、Web ページをレンダリングするために使用される外部リソースです。Django では、静的ファイルの保存場所とそのアクセス方法を構成して、これらのリソースが開発環境と運用環境の両方に正しく読み込まれるようにすることができます。

2.5.1 静的ファイルディレクトリの構成

Django プロジェクトの構成ファイルにはsettings.py、STATIC_URL静的ファイルの URL パスを定義するために使用されるという設定があります。これは、HTML ページを生成するときに静的ファイルが参照されるパスです。

STATIC_URL = '/static/'

デフォルト設定では、STATIC_URLに設定されています/static/。これは、すべての静的ファイル URL が/static/で始まることを意味します。

2.5.2 アプリケーション内の静的ファイル

通常、Django アプリケーションには、staticアプリケーションの静的ファイルを保持するというディレクトリが含まれています。これらのファイルはアプリケーションごとに編成されており、各アプリケーションには、アプリケーションに関連する静的リソースを含む独自のstaticディレクトリがあります。例えば：

myapp/
   ├── static/
   │   └── myapp/
   │       ├── css/
   │       │   └── style.css
   │       ├── js/
   │       │   └── script.js
   │       └── img/
   │           └── logo.png

上のツリーでは、myappアプリケーションに関連付けられたディレクトリがありstatic、CSS、JavaScript、および画像ファイルが含まれています。バックエンドの観点から見ると、ブートストラップや jquery 関連ファイルなど、一部のサードパーティの js および css ファイルはこれらのディレクトリに配置されるのが最も一般的です。

2.5.3 静的ファイルのロード

HTML テンプレートでは、{% static %}template タグを使用して静的ファイルをロードできます。このタグは、STATIC_URL設定に基づいて正しい URL パスを生成します。

<link rel="stylesheet" href="{% static 'myapp/css/style.css' %}">
<script src="{% static 'myapp/js/script.js' %}"></script>
<img src="{% static 'myapp/img/logo.png' %}" alt="Logo">

上の例では、{% static %}タグは静的ファイルへの相対パスを完全な URL に変換します。

2.5.4 静的ファイルの収集

運用環境では、Django は通常、そのままでは静的ファイルを提供しません。代わりに、パフォーマンスを向上させるために、これらのファイルを一元的な場所に収集します。次のコマンドを使用して静的ファイルを収集できます。

python manage.py collectstatic

これにより、アプリケーション内のすべての静的ファイルが指定されたディレクトリ (通常はプロジェクトのルートディレクトリの下のディレクトリ) に収集されますstatic/。

2.5.5 静的ファイルの構成オプション

Django は、次のような静的ファイルに関連する他の構成オプションも提供します。

STATIC_ROOT: 静的ファイルの収集に使用するルートディレクトリを指定します。デフォルトでは、これはプロジェクト root の下のディレクトリですstatic/。運用環境では、通常、Web サーバーがアクセスできるパスに設定する必要があります。
STATICFILES_DIRS: 追加で検索する静的ファイルのディレクトリを含むリスト。通常、アプリケーションレベルの静的ファイルではなく、プロジェクトレベルの静的ファイルを含めるために使用されます。

これらの構成オプションは、settings.pyプロジェクトの特定のニーズに合わせてカスタマイズできます。

静的ファイルディレクトリは Django プロジェクトの重要な部分であり、開発者が静的リソースを効果的に管理および提供して、Web サイトの外観と機能を適切に確保できるようにします。

2.6 テンプレートディレクトリ (Templates)

テンプレートディレクトリ ( Templates) は、Django プロジェクトで重要な役割を果たし、Web コンテンツの生成に使用される HTML テンプレートファイルを保存するために使用されます。Django のビュー関数は、リクエストに基づいてレンダリングに適切なテンプレートを選択し、生成された HTML ページをユーザーに返します。ここでは、テンプレートを検索して使用するように Django を構成する方法を含む、テンプレートディレクトリの詳細な説明を示します。

2.6.1 テンプレートディレクトリの構成

Django プロジェクトの構成ファイルには、テンプレート構成を含むリストであるという設定がsettings.pyあります。TEMPLATESこのリストの各ディクショナリは、テンプレートエンジンの構成を表します。通常、BACKENDテンプレートエンジンのバックエンドが指定され、DIRSテンプレートファイルが配置されているディレクトリが指定されます。

TEMPLATES = [
    {
    
    
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [],  # 在这里配置模板目录的路径
        'APP_DIRS': True,
        'OPTIONS': {
    
    
            'context_processors': [
                # ...
            ],
        },
    },
]

'DIRS': これは、テンプレートディレクトリへのパスを含むリストです。ここで、Django がテンプレートファイルを検索するカスタムテンプレートディレクトリを指定できます。たとえば、テンプレートファイルをプロジェクトのルートのtemplates/フォルダーに保存する場合は、これをのように構成できます'DIRS': [BASE_DIR / 'templates']。

2.6.2 APP_DIRS オプション

APP_DIRSはテンプレート設定のオプションです。に設定するとTrue、Django はインストールされている各アプリケーションのディレクトリ内で名前付きのサブディレクトリを検索しtemplates、それをテンプレートの検索パスに追加します。これは、各アプリケーションが独自のテンプレートディレクトリを持つことができることを意味し、アプリケーション内でテンプレートを整理しやすくなります。

2.6.3 テンプレートファイルの命名規則

通常、Django テンプレートファイルにはの拡張子が.html付いていますが、他の拡張子を使用することもできます。テンプレートは、理解しやすく、管理しやすいように、ビュー関数またはモデルに関連付けて名前が付けられることがよくあります。たとえば、という名前のアプリがある場合blog、そのアプリの記事リストページテンプレートの名前はとなりますarticle_list.html。

2.6.4 テンプレートの継承

Django のテンプレートシステムは、テンプレートを再利用可能なチャンクに分割する方法であるテンプレートの継承をサポートしています。このタグを{% block %}使用すると、基本テンプレートでブロックを定義し、子テンプレートでこれらのブロックをオーバーライドできます。これにより、一貫した外観とレイアウトのページを簡単に作成できるようになります。以下に例を示します。

基本テンプレートbase.html:

<html>
<head>
  <title>{% block title %}My Site{% endblock %}</title>
</head>
<body>
  <div id="content">
    {% block content %}{% endblock %}
  </div>
</body>
</html>

サブテンプレートarticle_list.html:

{% extends "base.html" %}
   
{% block title %}Article List{% endblock %}
   
{% block content %}
<h1>Article List</h1>
<!-- 页面内容 -->
{% endblock %}

上の例では、article_list.htmlテンプレートはbase.htmlテンプレートを継承し、titleブロックとcontentブロックをオーバーライドします。

2.6.5 テンプレートのタグとフィルター

Django は、テンプレート内のロジックを実行してデータを処理するための、豊富なテンプレートタグとフィルターのセットを提供します。ラベルは{% %}でラップされ、フィルターは{ { }}でラップされます。たとえば、{% for %}タグを使用してリストをループしたり、{ { value|filter }}構文を使用して変数をフィルターしたりできます。

{% for article in articles %}
  <h2>{
   
   { article.title }}</h2>
  <p>{
   
   { article.content|linebreaks }}</p>
{% endfor %}

2.6.6 テンプレートのロードシーケンス

Django テンプレートシステムは、通常は最も具体的なものから最も一般的なものへと、特定の順序でテンプレートファイルを検索します。まず、アプリケーションディレクトリでテンプレートを検索し、次にカスタムディレクトリ (構成されている場合)、最後に Django 組み込みテンプレートディレクトリを検索します。

これらは、Django テンプレートディレクトリに関する基本的な概念と構成です。テンプレートは、Django で動的 Web コンテンツを生成するための重要な部分であり、Web ページのコードをより明確かつモジュール形式で整理できるため、開発効率と保守性が向上します。

2.7 テストファイルディレクトリ (Tests)

単体テストと統合テストの作成と実行に使用される、プロジェクトのテストファイルが含まれています。

2.8 仮想分離環境

Python 仮想環境は、プロジェクトの依存関係を分離するために使用され、venv/プロジェクトのルートディレクトリの下に配置されたディレクトリに配置できます。仮想環境には、プロジェクトの依存関係がグローバル Python 環境と競合しないようにするために、プロジェクトに必要な Python パッケージが含まれています。ただし、これは必須ではありません。必要に応じて、仮想分離環境に簡単にアクセスできます。

3. Django 設定ファイル settings.py

以下は、上記の Django 設定ファイルの各部分のセクション分析ですsettings.py。

3.1 基本的なパスとファイルの生成

from pathlib import Path

BASE_DIR = Path(__file__).resolve().parent.parent

この部分では、BASE_DIR変数は現在の構成ファイルが配置されているディレクトリの上位ディレクトリに設定され、プロジェクト内の他のパスを構築するために使用されます。

3.2 開発セットアップをすぐに開始する

SECRET_KEY = 'django-insecure-*a00ec65jkjd119ed=e3+1w)gjh15b)7@5hp1z1mh(o*ev&7tg'
DEBUG = True
ALLOWED_HOSTS = []

キー、デバッグモード、許可されたホストなど、プロジェクトのいくつかのクイック開発オプションがここで設定されます。これらの設定は運用環境で変更する必要があることに注意してください。

SECRET_KEYおよびDEBUGこれらの構成項目を分析するとALLOWED_HOSTS、Django プロジェクトにおけるそれらの意味と役割を詳細に説明できます。

3.2.1`SECRET_KEY`設定

SECRET_KEY = 'django-insecure-*a00ec65jkjd119ed=e3+1w)gjh15b)7@5hp1z1mh(o*ev&7tg'

SECRET_KEYこれは Django プロジェクトの非常に重要な構成項目であり、ユーザーセッションやパスワードなどの機密データを暗号化して保護するために使用されます。このキーは、データの暗号化と復号化に使用されるシードです。

機能:
- ユーザーセッションの保護:SECRET_KEYユーザーセッションの署名と検証に使用され、ユーザーログインステータスのセキュリティを確保します。
- 暗号化されたパスワード: ユーザーのパスワードを保存および検証する場合、キーを使用してパスワードを暗号化および復号化し、機密性を確保します。
例:
通常、SECRET_KEYの値はランダムに生成された文字列です。次に例を示します。
```
SECRET_KEY = '2m_5#&^ihfw7z(b^^7+0^3wb*gj4%j4*#j%(9-ted-5q(^7p4z'
```
実稼働環境では、実際のキーを構成ファイルにハードコードせず、セキュリティを強化するために環境変数からロードする必要があります。

3.2.2`DEBUG`設定

DEBUG = True

DEBUG構成項目は、デバッグモードを有効にするかどうかを制御するために使用されます。開発中に、これはTrue詳細なエラー情報やデバッグツールを取得するために設定されることがよくあります。運用環境では、Falseセキュリティリスクを軽減するためにこれを設定する必要があります。

機能:
- デバッグモード:DEBUGに設定するとTrue、Django はアプリケーションの開発とデバッグのための詳細なエラーページ、スタックトレース、およびデバッグ情報を提供します。
- セキュリティ: 運用環境では、DEBUGに設定するとFalseエラーメッセージの露出が減り、アプリケーションのセキュリティが向上します。
例:
開発中に、詳細なエラー情報を表示するようにDEBUG設定できますTrue。False運用環境では、これを次のように設定する必要があります。
```
DEBUG = False
```

3.2.3`ALLOWED_HOSTS`設定

ALLOWED_HOSTS = []

ALLOWED_HOSTS構成項目は、アプリケーションへのアクセスを許可するホストのリストを定義するために使用されます。これは、アプリケーションに接続できるホストを制限するセキュリティ構成です。

機能:
- セキュリティ: 設定を通じてALLOWED_HOSTS、悪意のあるホストからのリクエストを防止し、それによってアプリケーションのセキュリティを向上させることができます。
- 複数のドメイン名を構成する: 複数のドメイン名または IP アドレスを追加して、ALLOWED_HOSTS複数のホストがアプリケーションにアクセスできるようにすることができます。
例:
運用環境では、実際のドメイン名または IP アドレスをに追加する必要がありますALLOWED_HOSTS。例:
```
ALLOWED_HOSTS = ['example.com', 'www.example.com', '192.168.1.100']
```
example.comこれにより、www.example.comと192.168.1.100アプリケーションへのアクセスが許可されますが、他のホストからのリクエストは拒否されます。

つまり、SECRET_KEY、、DEBUGおよびはALLOWED_HOSTSすべて Django プロジェクトの主要な構成項目であり、プロジェクトのセキュリティと動作に直接影響します。運用環境では、アプリケーションの安定性とセキュリティを確保するために、これらのオプションを慎重に構成することが重要です。

3.3 アプリケーションの定義

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

INSTALLED_APPSプロジェクトにインストールされているアプリケーションを一覧表示します。これらのアプリケーションには、管理インターフェイス、認証システムなど、Django によって提供されるいくつかの組み込みアプリケーションが含まれます。プロジェクト作成の開始時に、いくつかのデフォルトのフレームワークアプリケーションがインストールされていることがわかります。

以下は、いくつかのデフォルトの組み込みアプリケーションの紹介です。

3.3.1 django.contrib.admin

このアプリケーションは、データベース内のデータと Django アプリケーションの構成を管理するための強力な管理バックエンドインターフェイスを提供します。管理者ユーザーがデータベースレコードを簡単に追加、変更、削除できるようにします。管理者は、/admin パスにログインし、アプリケーションを使用してアプリケーションのデータベースデータを管理できます。

(例: http://127.0.0.1:8000/admin)
ここに画像の説明を挿入します

3.3.2 django.contrib.auth

このアプリケーションは、ユーザー登録、ログイン、パスワードリセット、ユーザーグループ、その他の機能を含むユーザー認証および認可システムを提供します。ユーザー、ユーザーグループ、権限を管理できます。ユーザーはアカウントを登録し、アプリケーションにログインし、認証が必要なビューにアクセスできます。

3.3.3 django.contrib.contenttypes

このアプリケーションは、一般的な関係の作成とモデル間の関連性の検索を可能にするコンテンツタイプフレームワークを提供します。ユニバーサル外部キー、逆関係、多態性関係の作成に使用できます。モデル間の関連付けを許可します。たとえば、コメントモデルを記事または画像モデルに関連付けることができます。

3.3.4 django.contrib.sessions

このアプリケーションは、Web アプリケーションでユーザーセッションデータを保存および取得するためのセッション管理機能を提供します。ユーザーのログインステータスを追跡および管理するために使用できます。セッションを使用して、ショッピングカートの内容、ユーザー設定などのデータを保存できます。

3.3.5 django.contrib.messages

このアプリは、成功、エラー、情報メッセージなどの 1 回限りのメッセージをユーザーに表示するためのメッセージ通知フレームワークを提供します。ユーザーが自分のアクションの結果についてフィードバックを得られるようにします。フォームの送信後に、成功またはエラーのメッセージをユーザーに表示できます。

3.3.6 django.contrib.staticfiles

このアプリケーションは、CSS、JavaScript、画像ファイルなどの静的ファイルの収集と提供を処理します。アプリケーション内の静的リソースを管理して、テンプレートで使用できるようにします。

3.4 ミドルウェアの設定

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

MIDDLEWAREこのリストには、要求および応答の処理中に実行されるミドルウェアが含まれています。ミドルウェアは、セキュリティ、セッション管理、認証などのさまざまなタスクを実行するために使用されます。

3.5 URL設定（ファイルの指定とルーティング）

ROOT_URLCONF = 'myproject.urls'

ROOT_URLCONFプロジェクト内で URL マッピングを定義するために使用されるモジュールを設定します。

3.6 テンプレートの設定

TEMPLATES = [
    {
    
    
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [],
        'APP_DIRS': True,
        'OPTIONS': {
    
    
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
        },
    },
]

TEMPLATESこのリストでは、テンプレートディレクトリやコンテキストプロセッサなど、プロジェクト内のテンプレートエンジンのオプションを構成します。

3.7 WSGIアプリケーションの設定

WSGI_APPLICATION = 'myproject.wsgi.application'

WSGI_APPLICATIONプロジェクトの定義に使用する WSGI アプリケーションをセットアップします。

3.8 データベースの構成

DATABASES = {
    
    
    'default': {
    
    
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
    }
}

DATABASESディクショナリには、データベースエンジンやデータベースファイルパスなど、プロジェクトデータベースの構成オプションが含まれています。

で：

'BACKEND': 使用するテンプレートエンジンバックエンドを指定するために使用されます。たとえば、'django.template.backends.django.DjangoTemplates'Django にはテンプレートエンジンバックエンドが付属しているため、通常はこれをに設定する必要があります。
'DIRS': 追加のテンプレートディレクトリパスのリストが含まれます。これらのパスは、カスタムテンプレートファイルを検索するために使用されます。たとえば、プロジェクトのルートのtemplatesフォルダーにカスタムテンプレートが保存されている場合は、このリストにパスを追加できます。'DIRS': [BASE_DIR / 'templates'],
'APP_DIRS': アプリケーション内のテンプレートディレクトリを検索するかどうかを指定します。たとえば、Trueアプリケーションのテンプレートディレクトリ検索を有効にするには、に設定します。
'OPTIONS': 追加のテンプレートエンジンオプションを含むディクショナリ。たとえば、では'OPTIONS'、次のように他のオプションを設定できます。
```
'OPTIONS': {
      
      
    'context_processors': [  # 上下文处理器
        'django.template.context_processors.debug',  # 调试信息
        'django.template.context_processors.request',  # 请求对象
        'django.contrib.auth.context_processors.auth',  # 认证用户
        'django.contrib.messages.context_processors.messages',  # 消息通知
    ],
    'builtins': [
        'myapp.template_tags.my_template_tag',  # 自定义模板标签
    ],
},
```
- 'context_processors'リストには、テンプレートに追加のコンテキストデータを提供できるコンテキストプロセッサの名前が含まれています。たとえば、'django.contrib.auth.context_processors.auth'認証されたユーザー情報がテンプレートに提供されます。
- 'builtins'テンプレートで使用するための組み込みのタグとフィルターが含まれています。カスタムテンプレートタグがある場合は、それをこのリストに追加できます。

これらの構成アイテムにより、テンプレートディレクトリ、コンテキストプロセッサ、組み込みタグなど、プロジェクト内のテンプレートエンジンの動作をカスタマイズできます。プロジェクトのニーズに応じて、テンプレートエンジンを柔軟に構成できます。

3.9 パスワード認証の設定

AUTH_PASSWORD_VALIDATORS = [
    {
    
    
        'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
    },
    {
    
    
        'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
    },
    {
    
    
        'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
    },
    {
    
    
        'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',
    },
]

AUTH_PASSWORD_VALIDATORSこのリストでは、ユーザーパスワードのセキュリティを確保するためのパスワード検証ポリシーを定義します。上記のデフォルト設定では次のようになります。

'django.contrib.auth.password_validation.UserAttributeSimilarityValidator':
このバリデータは、パスワードがユーザーの属性に類似しすぎているかどうかをチェックするために使用されます。パスワードとユーザーの属性 (ユーザー名など) の類似性を比較し、設定された類似性要件に基づいてパスワードが安全かどうかを判断します。
'django.contrib.auth.password_validation.MinimumLengthValidator':
このバリデータは、パスワードの最小長が満たされていることを確認します。パスワードの長さの最小要件は、Django の設定で設定できます。
'django.contrib.auth.password_validation.CommonPasswordValidator':
このバリデータは、パスワードに「password」や「123456」などの一般的な弱いパスワードが含まれているかどうかを確認するために使用されます。一般的なパスワードのリストと照合してパスワードの強度をチェックします。
'django.contrib.auth.password_validation.NumericPasswordValidator':
このバリデータは、パスワードに数字が含まれているかどうかを確認するために使用されます。パスワードには少なくとも 1 つの数字が含まれている必要があります。

これらのバリデーターをリストに追加することでAUTH_PASSWORD_VALIDATORS、Django はパスワードのセキュリティを確保し、ユーザーが単純すぎるパスワードや推測しやすいパスワードを使用することを防ぎます。これにより、システムのセキュリティが向上し、パスワードが悪意のある攻撃や解読されるのを防ぐことができます。これらのバリデーターはカスタマイズしたり、プロジェクトのセキュリティ要件に基づいてカスタムバリデーターを追加したりできます。

3.10 国際化とタイムゾーンの設定

LANGUAGE_CODE = 'en-us'
TIME_ZONE = 'UTC'
USE_I18N = True
USE_TZ = True

これらの設定は、プロジェクトの国際化とタイムゾーンを構成するために使用されます。

以下は、Django の国際化とタイムゾーン設定の分析です。取得できる値と各値の意味も含まれます。

3.10.1`LANGUAGE_CODE`

は文字列です (例'en-us':'es-es'など) 。
この設定では、プロジェクトのデフォルトの言語とロケールを指定します。これにより、プロジェクトで使用される言語と、日付、時刻、数値の形式が決まります。

たとえば、'en-us'use はアメリカ英語、 use'zh-hans'は簡体字中国語、 use'zh-hant'は繁体字中国語、 use は'fr'フランス語、 use はスペイン語、 use'es-es'は'ru'ロシア語、 use はペルシア語、 use は日本語'fa'、 use は'ja'韓国語'ko'、 use は'la'ラテン語などを意味します。

3.10.2`TIME_ZONE`

は文字列です (例'UTC':'America/New_York'など) 。
この設定では、プロジェクトのデフォルトのタイムゾーンを指定します。これは日付と時刻に関連するすべての操作に影響し、指定されたタイムゾーンに従って操作が計算および表示されるようにします。たとえば、'UTC'協定世界時を表すには、'America/New_York'東部時間を表します。

3.10.3`USE_I18N`

ブール値 (TrueまたはFalse) です。
この設定は、国際化が有効かどうかを示します。に設定すると、Djangoは日付、時刻、数値の形式などの設定に従ってプロジェクトコンテンツをローカライズしよTrueうとします。LANGUAGE_CODEたとえば、True国際化が有効であることを意味し、False国際化が無効であることを意味します。

3.10.4`USE_TZ`

ブール値 (TrueまたはFalse) です。
この設定は、タイムゾーンのサポートが有効かどうかを示します。に設定するとTrue、Django はTIME_ZONEその構成を使用して日付と時刻を処理し、指定されたタイムゾーンで日付と時刻が正しく表示および計算されるようにします。たとえば、Trueはタイムゾーンサポートが有効であることを示し、Falseはタイムゾーンサポートが無効であることを示します。

これらの設定を使用すると、プロジェクトの国際化とタイムゾーンをカスタマイズして、アプリケーションがさまざまな地域やロケールで正しく動作するようにすることができます。プロジェクトのニーズに応じて、上記の手順に従ってこれらの設定を構成できます。

3.11 静的ファイルの設定

STATIC_URL = 'static/'

STATIC_URL静的ファイルの定義に使用される URL パス。Django では、静的ファイルには通常、Web サイトのスタイル設定やインタラクティブ機能に使用される CSS、JavaScript、画像、その他のフロントエンドリソースが含まれます。Web サイト内の静的ファイルのルート URL パスを定義します。

たとえば、がSTATIC_URLに設定されている場合'static/'、静的ファイルはで始まりURLますhttp://example.com/static/。

通常、STATIC_URL の設定は、静的ファイルの URL パスが正しいことを保証するためにスラッシュで終わります。これは、Django では静的ファイルの URL パスがルート URL からの相対パスであるためです。

静的ファイルは通常、プロジェクトのstaticディレクトリに保存され、STATIC_URLこれらの静的ファイルにアクセスする方法が指定されています。

たとえば、ディレクトリにstyle.cssという名前の CSS ファイルがある場合、 +を使用してアクセスできます。static/css/STATIC_URL'css/style.css'

STATIC_URL を使用する利点は、プロジェクトをさまざまな環境 (開発、テスト、運用環境など) にデプロイする必要がある場合に、テンプレート内の静的ファイルパスを変更せずに、STATIC_URL の設定を変更するだけで済むことです。これにより、プロジェクトの保守性と移植性が向上します。

3.12 デフォルトの主キーフィールドタイプの設定

DEFAULT_AUTO_FIELD = 'django.db.models.BigAutoField'

DEFAULT_AUTO_FIELDモデルのデフォルトの主キーフィールドタイプを定義するために使用されます。この設定はDjango 3.2以降のバージョンで導入され、モデルのデフォルトの主キーフィールドタイプを指定するために使用されます。

DEFAULT_AUTO_FIELDさまざまな異なる値に設定でき、各値は異なるプロジェクトのニーズを満たすために異なる主キーフィールドタイプに対応します。

'django.db.models.AutoField':
これは、Django のデフォルトの主キーフィールドタイプです。32ビット整数型の主キー値を自動生成します。ほとんどの中小規模のアプリケーションに適しています。
'django.db.models.BigAutoField'：
64ビット整数型の主キー値を自動生成します。主キー値のオーバーフローを避けるために大規模なデータセットを処理するのに適しています。
'django.db.models.UUIDField':
UUID (Universally Unique Identifier) を主キーとして使用します。複数のデータベースまたは分散システム間のデータのマージに適した、グローバルに一意の主キー値を生成します。
カスタム主キーフィールドタイプ:
独自のカスタム主キーフィールドタイプを定義し、DEFAULT_AUTO_FIELDそれらをで参照することもできます。models.Fieldこれには、を継承するカスタムフィールドクラスを作成する必要があります。例えば：
```
# 自定义主键字段类型
from django.db import models

class MyCustomPrimaryKey(models.Field):
    def db_type(self, connection):
        return 'my_custom_type'

# 在 settings.py 中使用自定义主键字段类型
DEFAULT_AUTO_FIELD = 'myapp.models.MyCustomPrimaryKey' # myapp 表示 Django 项目中的一个应用（app）的名称。
```
ここで、myapp はダミーのサンプルアプリ名です。実際のプロジェクトのアプリ名に置き換える必要があります。実際、DEFAULT_AUTO_FIELD 設定には、カスタム主キーフィールドを含むアプリとモデルへの参照が必要です。これは、プロジェクト内のアプリケーションのモデルでカスタム主キーフィールドを定義する必要があるためです。したがって、myapp.models.MyCustomPrimaryKey の myapp はアプリケーションの名前、models はカスタム主キーフィールドを含むアプリケーション内の Python モジュール、MyCustomPrimaryKey はカスタム主キーフィールドの名前です。つまり、プロジェクト内に実際に myapp という名前のアプリケーションがあり、MyCustomPrimaryKey フィールドがアプリケーションの models.py ファイルで定義されている場合は、上記の設定を使用できます。それ以外の場合は、myapp を実際のアプリ名に置き換え、カスタム主キーフィールドがアプリのモデルに存在することを確認してください。

設定を使用すると、DEFAULT_AUTO_FIELDプロジェクトのニーズに合わせて、パフォーマンスとデータ管理の要件を満たすデフォルトの主キーフィールドタイプを選択できます。さまざまな主キーフィールドの種類がさまざまなシナリオに適しており、プロジェクトの特性に応じて選択できます。

F. 添付: 実際の初期設定ファイル

"""
Django settings for myproject project.

Generated by 'django-admin startproject' using Django 4.2.5.

For more information on this file, see
https://docs.djangoproject.com/en/4.2/topics/settings/

For the full list of settings and their values, see
https://docs.djangoproject.com/en/4.2/ref/settings/
"""

from pathlib import Path

# Build paths inside the project like this: BASE_DIR / 'subdir'.
BASE_DIR = Path(__file__).resolve().parent.parent


# Quick-start development settings - unsuitable for production
# See https://docs.djangoproject.com/en/4.2/howto/deployment/checklist/

# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = 'django-insecure-*a00ec65jkjd119ed=e3+1w)gjh15b)7@5hp1z1mh(o*ev&7tg'

# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = True

ALLOWED_HOSTS = []


# Application definition

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

ROOT_URLCONF = 'myproject.urls'

TEMPLATES = [
    {
    
    
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [],
        'APP_DIRS': True,
        'OPTIONS': {
    
    
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
        },
    },
]

WSGI_APPLICATION = 'myproject.wsgi.application'


# Database
# https://docs.djangoproject.com/en/4.2/ref/settings/#databases

DATABASES = {
    
    
    'default': {
    
    
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
    }
}


# Password validation
# https://docs.djangoproject.com/en/4.2/ref/settings/#auth-password-validators

AUTH_PASSWORD_VALIDATORS = [
    {
    
    
        'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
    },
    {
    
    
        'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
    },
    {
    
    
        'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
    },
    {
    
    
        'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',
    },
]


# Internationalization
# https://docs.djangoproject.com/en/4.2/topics/i18n/

LANGUAGE_CODE = 'en-us'

TIME_ZONE = 'UTC'

USE_I18N = True

USE_TZ = True


# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/4.2/howto/static-files/

STATIC_URL = 'static/'

# Default primary key field type
# https://docs.djangoproject.com/en/4.2/ref/settings/#default-auto-field

DEFAULT_AUTO_FIELD = 'django.db.models.BigAutoField'

Django シリーズ: Django プロジェクトの構造と構成の分析

目次