Skip to main content

Django 介绍

tip

使用 Django 3.1 进行操作, 虽然已经更新到了 5 版本, 但是没必要追太新, 旧版本学会了后面补一下就可以了

介绍​

Django 作为 Python 的一个 Web 框架, 其功能全面而且使用范围广, 采用 MTV 模式

在 Django 开发中使用 APP 模式进行开发, 也就是将功能分成多个 APP 比如 : 登陆APP 、聊天 APP 这类, 我们可以在一个项目中添加多个 APP 进行操作或者在多个项目中引用一个 APP , 这样的操作可以从一定角度简化开发以及便于维护迭代

MVC/MTV 介绍​

MVC​

tip

百度百科：全名Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件工程典范，用业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。

通俗解释：一种代码和文件的组织和管理形式！不要被缩写吓到了，这其实就是把代码分散到不同的文件中，把不同类型的文件又放到不同目录下的一种做法，然后取了个高大上的名字。当然，它带来的好处有很多，比如前后端分离，松耦合等等，在使用中你慢慢体会就会逐渐明白它。

其中:

  • 模型(model) : 定义数据库相关的内容，一般放在models.py文件中。
  • 视图(view)：定义HTML等静态网页文件相关，也就是那些HTML、CSS、JS等前端的东西。
  • 控制器(controller)：定义业务逻辑相关，就是你的主要代码。

MTV​

Django对传统的MVC设计模式进行了修改，将视图分成View模块和Template模块两部分，将动态的逻辑处理与静态的页面展示分离开。而Model采用了ORM技术，将关系型数据库表抽象成面向对象的Python类，将数据库的表操作转换成Python的类操作，避免了编写复杂的SQL语句。

  • 模型(model) : 定义数据库相关的内容，一般放在models.py文件中。
  • 模板(Template)：将模型数据与HTML页面结合起来的引擎
  • 视图(View)：负责实际的业务逻辑实现

Django的MTV模型组织可参考下图所示：

20240419190541

Django 环境安装&配置&使用​

$ django-admin.exe startproject projectName # 创建一个 Django 项目
$ python manage.py startapp APPName # 创建一个 APP
$ python manage.py runserver # 启动 Django 项目
$ python manage.py check # 检测 Django 项目的配置等等内容
$ python manage.py createsuperuser # 创建一个 admin 管理账户
$ python manage.py migrate # 遍历 INSTALLED_APPS 中的所有项目, 在数据库中创建对应的表
$ python manage.py makemigrations APPName # 将APPName 模型文件保存为一个 “迁移(migration)”。
tip

注意 : Django 的开发服务器具有自动重载的功能, 当你的Python代码有修改，服务器会在一个周期后自动更新, 但是，有一些动作，比如增加文件，不会触发服务器重载，这时就需要你自己手动重启。所以建议，在任何修改代码的操作后，手动重启开发服务器，确保修改被应用。

配置文件的设置​

在实际开发中， 有一些设置经常需要改动， 如下所示:

settings.py
TIME_ZONE = 'Asia/Shanghai' # 时区设置

APP 配置​

Django 会根据 INSTALLED_APPS 配置项, 来加载和激活 APP, 因此如果我们创建一个 APP 需要在此进行注册操作

INSTALLED_APPS = [
    'django.contrib.admin', # admin管理后台站点
    'django.contrib.auth', # 身份认证系统
    'django.contrib.contenttypes', # 内容类型框架
    'django.contrib.sessions', # 会话框架
    'django.contrib.messages', # 消息框架
    'django.contrib.staticfiles', # 静态文件管理框架
]

数据库配置​

在 Django 中默认使用 SQLite3 数据库, 因为Python原生支持SQLite3数据库, 当然也可以根据自己的需要进行灵活设置, 下面是数据库默认配置

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

如果想要修改使用其他数据库, 需要安装对应的数据库操作模块, 并修改文件中 DATABASES 配置内容:

  • ENGINE : 数据库的引擎, 比如 django.db.backends.sqlite3、django.db.backends.postgresql、django.db.backends.mysql、 django.db.backends.oracle
  • NAME : 数据库的名称, 类似Mysql数据库管理系统中用于保存项目内容的数据库的名字
注意事项
  • 在使用非 SQLite3 数据库时, 需要先创建对应的数据库, Django 不会帮助我们做着一步工作
  • 确保提供的用户在数据库中具有创建数据表的权限

下面将介绍在实际使用中会使用到的命令以及对应的描述信息 (PS : 本例内容来自 第一个 Django 案例), 在案例中创建了 polls APP 并将其注册到了 Django 项目中, 随后执行下面的命令

(.venv) PS C:\Users\14894\Desktop\Django\oneDjango> py.exe .\manage.py makemigrations polls
Migrations for 'polls':
  apps\polls\migrations\0001_initial.py
    - Create model Question
    - Create model Choice

通过运行 makemigrations 命令, Django 就会检测 polls APP 的模型文件的修改, 并模型文件的修改保存为一个 迁移(migration)

migrations是Django保存模型修改记录的文件，这些文件保存在磁盘上。在例子中，它就是 polls/migrations/0001_initial.py，里面保存的都是人类可读并且可编辑的内容，方便随时手动修改。当上述操作完毕之后, 就可以进行迁移操作将模型体现到数据库具体表中

生成迁移文件的必要性

当我们想要使用 Github 提交项目代码, 如果没有一个中间过程的保存文件（migrations），那么github如何知道以及记录、同步、实施你所进行过的模型修改动作呢？毕竟，github不和数据库直接打交道，也没法和你本地的数据库通信。但是分开之后，你只需要将你的migration文件（例如上面的0001）上传到github，它就会知道一切。

(.venv) PS C:\Users\14894\Desktop\Django\oneDjango> py.exe .\manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, polls, sessions
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying auth.0010_alter_group_name_max_length... OK
  Applying auth.0011_update_proxy_permissions... OK
  Applying auth.0012_alter_user_first_name_max_length... OK
  Applying polls.0001_initial... OK
  Applying sessions.0001_initial... OK

migrate 命令对所有还未实施的迁移记录进行操作，本质上就是将你对模型的修改体现到数据库中具体的表中。Django通过一张叫做django_migrations的表，记录并跟踪已经实施的migrate动作，通过对比获得哪些迁移尚未提交。

迁移的功能非常强大，允许你随时修改你的模型，而不需要删除或者新建你的数据库或数据表，在不丢失数据的同时，实时动态更新数据库。

模型操作三步骤
  1. 在 models.py 中修改模型
  2. 运行 python manage.py makemigrations 为改动创建迁移记录文件；
  3. 运行 python manage.py migrate 将操作同步到数据库。

同时还存在一些可以扩展的命令, 可以帮助我们进行操作

$ python manage.py sqlmigrate polls 0001 # 展示在执行迁移操作时要执行的 SQL 语句是什么

数据库-模型自带 API​

模板命名空间​

在项目settings.py文件中的 TEMPLATES配置项描述了 Django 如何载入和渲染模板。默认的设置文件设置了 DjangoTemplates 后端作为模板引擎，并将 APP_DIRS设置成了 True。这一选项将会让 DjangoTemplates 在每个 INSTALLED_APPS 文件夹中寻找 "templates" 子目录。

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',
            ],
        },
    },
]

因此在默认情况下, 我们会在每一个 APP 中添加一个新的目录 templates, 之后再创建一个新的子目录名为 polls(其实就是你的 AppName), 进入该子目录，创建一个新的HTML文件index.html。换句话说，你的模板文件应该是polls/templates/polls/index.html。因为 Django 会寻找到对应的app_directories ，所以你只需要使用polls/index.html就可以引用到这一模板.

Question Icon为什么不把模板文件直接放在 polls/templates 目录下，而是费劲的再建个子目录polls呢?

设想这么个情况，有另外一个app，它也有一个名叫index.html的文件，当Django在搜索模板时，有可能就找到它，然后退出搜索，这就命中了错误的目标，不是我们想要的结果。解决这个问题的最好办法就是在templates目录下再建立一个与app同名的子目录，将自己所属的模板都放到里面，从而达到独立命名空间的作用，不会再出现引用错误。

静态命名空间​

Django的STATICFILES_FINDERS设置项中包含一个查找器列表，它们知道如何从各种源中找到静态文件。 其中一个默认的查找器是AppDirectoriesFinder，它在每个INSTALLED_APPS下查找static子目录，例如我们刚创建的那个static目录。admin管理站点也为它的静态文件使用相同的目录结构。

与模板类似，我们可以将静态文件直接放在polls/static（而不是创建另外一个polls 子目录），但实际上这是一个坏主意。Django将使用它所找到的第一个匹配到的静态文件，如果在你的不同应用中存在两个同名的静态文件，Django将无法区分它们。我们需要告诉Django该使用其中的哪一个，最简单的方法就是为它们添加命名空间。也就是说，将这些静态文件放进以它们所在的应用的名字同名的另外一个子目录下（白话讲：多建一层与应用同名的子目录）。

学习资料​