Django Web开发学习笔记（5）

2024-01-15 12:50:52

第五部分 Model 层

创建一个app工程。app和project的区别引用DjangoBook的说法是：

一个project包含很多个Django app以及对它们的配置。

技术上，project的作用是提供配置文件，比方说哪里定义数据库连接信息, 安装的app列表， TEMPLATE_DIRS ，等等。

一个app是一套Django功能的集合，通常包括模型和视图，按Python的包结构的方式存在。

例如，Django本身内建有一些app，例如注释系统和自动管理界面。 app的一个关键点是它们是很容易移植到其他project和被多个project复用。

一、创建app包

python manage.py startapp yourappName [yourappDestination]

观察一下默认生成的文件的名字：

yourappName--------

--------__init__.py

--------admin.py

--------models.py

　　　　　　 --------tests.py

--------views.py

我们早些时候谈到。MTV里的M代表模型。 Django模型是用Python代码形式表述的数据在数据库中的定义。对数据层来说它等同于 CREATE TABLE 语句，只不过执行的是Python代码而不是 SQL，而且还包含了比数据库字段定义更多的含义。 Django用模型在后台执行SQL代码并把结果用Python的数据结构来描述。 Django也使用模型来呈现SQL无法处理的高级概念。(DjangoBook)

自省（运行时自动识别数据库）会导致过载和有数据完整性问题。为了提供方便的数据访问API， Django需要以 某种方式 知道数据库层内部信息，有两种实现方式。第一种方式是用Python明确地定义数据模型，第二种方式是通过自省来自动侦测识别数据模型。

第二种方式看起来更清晰，因为数据表信息只存放在一个地方-数据库里，但是会带来一些问题。首先，运行时扫描数据库会带来严重的系统过载。如果每个请求都要扫描数据库的表结构，或者即便是服务启动时做一次都是会带来不能接受的系统过载。（有人认为这个程度的系统过载是可以接受的，而Django开发者的目标是尽可能地降低框架的系统过载）。第二，某些数据库，尤其是老版本的MySQL,并未完整存储那些精确的自省元数据。

编写Python代码是非常有趣的，保持用Python的方式思考会避免你的大脑在不同领域来回切换。尽可能的保持在单一的编程环境/思想状态下可以帮助你提高生产率。不得不去重复写SQL，再写Python代码，再写SQL，…，会让你头都要裂了。

把数据模型用代码的方式表述来让你可以容易对它们进行版本控制。这样，你可以很容易了解数据层的变动情况。

SQL只能描述特定类型的数据字段。例如，大多数数据库都没有专用的字段类型来描述Email地址、URL。而用Django的模型可以做到这一点。好处就是高级的数据类型带来更高的效率和更好的代码复用。

SQL还有在不同数据库平台的兼容性问题。发布Web应用的时候，使用Python模块描述数据库结构信息可以避免为MySQL, PostgreSQL, and SQLite编写不同的CREATE TABLE。

二、创建模型

打开model.py并添加下面的语句：

from django.db import models

# Create your models here.
class Student(models.Model):
    name = models.charField(max_length=30)
    address = models.charField(max_length = 50)
    city = models.charField(max_length=30)
    grade = models.charField(max_length = 20)
    website = models.URLField()

class School(models.Model):
    name = models.charField(max_length=30)
    city = models.ManyToManyField(Student)
    createDate = models.DateField()

这类似于SQL中创建表的语句。charField可以理解为数据库中的varchar()字段。另外需要注意的是表School中的几种特殊的数据结构：

ManyToManyField(Student).

“每个数据库表对应一个类”这条规则的例外情况是多对多关系。School有一个 多对多字段 叫做 Student 。该字段表明一个学校可以有很多名的学生，Django创建了一个额外的表（多对多连接表）来处理这种映射关系。

最后需要注意的是，我们并没有显式地为这些模型定义任何主键。除非你单独指明，否则Django会自动为每个模型生成一个自增长的整数主键字段每个Django模型都要求有单独的主键。也就是每条记录的id.

三、模型安装

我们创建完APP后，怎样将我们的APP与Project进行连接起来呢？上面我们看到,project的作用是提供配置文件，安装APP.因此我们可以猜到是放置在创建工程时自动生成的__setting__目录下面

再次编辑 settings.py 文件，找到 INSTALLED_APPS 设置。 INSTALLED_APPS 告诉 Django 项目哪些 app 处于激活状态。

INSTALLED_APPS = (
    ‘django.contrib.admin‘,
    ‘django.contrib.auth‘,
    ‘django.contrib.contenttypes‘,
    ‘django.contrib.sessions‘,
    ‘django.contrib.messages‘,
    ‘django.contrib.staticfiles‘,
)

我们在这个元组型数据中添加如下代码：

‘DjangoE_1.formEtc"

下面我们就可以创建表了。在创建表之前我们应该先检查模型的有效性，执行

Python manage.py validate

执行结果为：0 error found 表明创建的模型是正确的

创建模型成功后，我们生成SQL表，执行

Python manage.py sqlall yourAppName

执行结果输出如下：

我们可以看到，输出结构就是我们创建的模型的SQL语句形式。注意中间生成的school_city的映射表。就是我们上面提到的ManyToMany结构时生成的映射关系表。分别以school_id和student_id作为字段进行关联。

sqlall 命令并没有在数据库中真正创建数据表，只是把SQL语句段打印出来，这样你可以看到Django究竟会做些什么。如果你想这么做的话，你可以把那些SQL语句复制到你的数据库客户端执行，或者通过Unix管道直接进行操作（例如，`` python manager.py sqlall books | psql mydb`` ）。不过，Django提供了一种更为简易的提交SQL语句至数据库的方法： `` syncdb`` 命令

python manage.py syncdb

该命令会将你创建的SQL 语句同步到你的数据库中