1.2 编写博客的数据模型类

1.2 编写博客的数据模型类

 

在Django中，不需要通过SQL语句直接跟数据库打交道，而是完全用Python的方式创建数据模型，之后交给Django完成数据库的操作。

 

1.2.1 数据模型类

 

利用Django开发网站系统，一般情况下，先编写数据模型，就是在./blog/models.py中写一个类，这个类与数据库中的数据表具有对应关系。

在./blog/models.py中编写博客的数据模型类Blog类，本质上它是一个继承了django.db.models.Model的类。

from django.db import models
from django.utils import timzone
from django.contrib.auth.models import User

#在这个类中，定义了一些属性，每个属性对应着数据库表中的一个字段。
class BlogArticles(models.Model):
    #规定字段title的属性为CharField()类型，且以参数max_length=300的形式说明字段的最大数量。
    title = models.CharField(max_length=300)
    #字段author规定了博客文章和用户之前的关系---一个用户对应多篇文章，ForeignKey()反映了"一对多"关系。
    #类User就是BlogArticles的对应对象，related_name="blog_posts"的作用是允许通过类User反向查询到BlogArticles。
    author = models.ForeignKey(User,on_delete=models.CASCOD,Erelate_name="blog_posts")
    boody = models.TextField()
    publish = models.DateTimeField(default=timezone.now)

#规定了BlogArticles实例对象的显示顺序，即按照publish字段值的倒序显示。
class Mate:
    ordering = ("-publish",)

def __str__(self):
    return self.title 

补充：on_delete 的五个属性是

补充：django数据模型字段常用类型

 

 

 

如何根据数据模型建立数据库表呢？

只需在/website/manage.py位置执行python manage.py makemigrations,结果如下图：

提示信息说在blog/migrations目录中创建了一个BlogArticles模型。不是手动编写的，而是执行上述代码之后Django自动生成的。是创建了一个名为blog_blogarticles的数据库表。由应用的名称+_+在models.py中创建的数据模型类的名称.

上面创建了一个能够建立数据库表的文件，下面真正创建数据库了。

使用SQLite工具查看创建的数据库和表。

 

1.2.2 发布博客文章

方法一：

使用Django默认的管理功能发布文章。要使用此功能，必须先创建超级管理员。

创建超级管理员的方法如下：

重新启动服务

在浏览器中打开并输入超级管理员的用户名和密码，如下图所示

Group和User是Django在用户管理应用中默认的。单击User会看到当前项目仅有的一个用户admin，当然可以增加用户。

 

在./blog/admin.py文件中，用编辑工具输入如下代码。

在调试状态下，如果没有新增加的文件，只是将原有文件修改了，则不需要重新启动Django服务（如果Django服务没有启动，请确保启动），然后打开浏览器，刷新页面，如下图所示。

这时可以看到新注册的BLOG。

单击Blog articles右侧的“Add”按钮可以添加博客文章，如下图所示。

内容填好后，单击页面右下角的“SAVE”按钮，该博客文章将被保存到数据库中，可以再次使用SQLiteStudio查看数据库，如下图所示：

注意：在发布文章时选择admin为author，并且admin在User中的id是1，所以这里记录了它的id值，即author_id为1-------这就是BlogArticles类中ForeignKey()属性的效果。

为后续操作需要，建议多发布几篇文章。

在./blog/models.py中使用了django.utils.timezone，为此需要安装一个模块pytz，用它来提供时区数值。

安装完毕，重启服务。

在文章的列表页，可以看到所有已经发布的文章的标题，如下图所示。

 这样显示的列表信息太单一了，还可以在./blog/admin.py中多写点东西，继续编辑./blog/admin.py，增加部分代码之后的文件内容如下：

from django.contrib import admin

#将BlogArticles类引入到当前环境

from .models import BlogArticles #①

 

class BlogArticlesAdmin(admin.ModelAdmin):

list_display = ("title","author","publish")

list_filter = ("publish","author")

search_fields = ("title","body")

# 这个体现在添加文章时,有这条你的作者是选择user的id,没这个是选择用户名

raw_id_fields = ("author",)

date_hierarchy = "publish"

ordering = ['publish','author']

# 将该类注册到admin中

# Register your models here.

admin.site.register(BlogArticles,BlogArticlesAdmin) #②

 

补充：关于admin这几个设置

 

修改./blog/admin.py后进行保存，然后刷新浏览器页面，会呈现如下图所示的效果。

1.2.3知识点

1、什么是HTTP

HTTP是Hyper Text Transfer Protocol(超文本传输协议)的缩写，是客户端(比如计算机的浏览器、网站爬虫程序)和服务端(网站)请求和应答的标准(TCP),封装了Web服务的整个过程。

通常，由客户端发起请求，建立到服务器指定端口（默认是80端口）的TCP连接。服务器在指定端口监听客户端的请求，一旦收到，就向客户端返回状态信息（比如“HTTP/1.1 200”）和内容信息（如请求的文件、错误消息或者其他信息），这就是响应。

HTTP要做的事情如下：

• 请求（request）：客户端到服务器。
• 响应（response）：服务器到客户端。

HTTP/1.1协议共定义了8种请求方式，分别是：OPTIONS、HEAD、GET、POST、PUT、DELETE、TRACE和CONNECT。注意这些请求方式的名称都是大写，不要用小写。主要使用GET和POST两种请求。

• GET：向指定的服务器发出请求，主要用于读取信息并显示。
• POST：向指定服务器提交数据，请求服务器进行处理（例如提交表单或者上传文件）

HTTPS全称是Hyper Text Transfer Protocol Secure，默认的端口为443.相比HTTP，HTTPS安全性更高，因为HTTP以明文方式封装信息，如果被某些所谓的抓包工具获得，则很容易分析出其内容，而HTTPS以加密的方式传送信息，这也是它逐渐流行的原因。

2、什么是URL

URL的全称是Uniform/Universal Resource Locator，翻译为中文是“统一资源定位符”，俗称网页地址（网址）。有了URL，就标志着步入了网络时代。

URL的标准格式是：协议类型://服务器地址(必要时需加上端口号)/路径/文件名。

• 协议类型：可以是HTTP，也可以是HTTPS。
• 服务器地址：通常为域名，比如itdiffer.com，也可以是IP地址。如果是默认的80端口，则不需要写，否则需要写上端口。
• 路径：以“/”区别目录。对于GET请求方式，还可以用“?”发起参数，每个参数以“&”隔开，再以“=”分开参数名称与值。
• 文件名：如果有必要可以写上，有时可以省略，由服务器根据路径匹配相应程序文件。

3、模型：ORM

早期网站：把需要在网页上呈现的信息直接写到HTML文件中，这种是静态的。（静态网页）

动态内容：当用户发起访问请求时，网站实时地从数据库提取内容并呈现在网页上。

在这类动态网站中，大多数是通过数据库实现对数据的保存和读取的，所以数据库是玩这个张最进本和底层的组成部分。

Python本身有读取数据库的模块，所以可以通过SQL语句直接实现程序和数据库的交互。

Django用不需要开发者使用SQL语句这种方式，而是使用更Python化的方式实现对数据库的操作，这就是ORM，即Object-Relational Mapping（对象关系映射）。

ORM的作用：在关系型数据库和业务实体对象之间进行映射，在操作业务对象时，不需要再去和复杂的SQL语句打交道，只需简单地操作对象的属性和方法。

Django的数据模型层大量使用ORM的优点：

• 可移植性强。本书中使用SQLite数据库，如果想改为MySQL数据库，只需要在settings.py文件中做好新数据库的配置，然后进行迁移数据的操作即可完成数据库的移植，不需要对ORM进行任何修改。
• 安全性好。使用ORM很少或者不需要执行SQL，就不必担心SQL注入等形式的攻击了，ORM还提供了一个自动引用和转义输入变量的机制，开发者不用在安全性的问题上花费太多时间，可将精力集中在程序的业务逻辑和开发上。
• 查询语法简单。

以上三点，让我们至少在相当一部分项目中使用Django封装的这个数据模型层完成对数据库的操作。（中小项目）

 Django的ORM表现方式就是编写数据模型类，这些类可以写在任何文件中，通常写在每个应用的models.py文件中。每个数据模型类都是django.db.models.Model的子类。应用的名称（小写字母）和数据模型类的名称（小写字母）共同组成一个数据库表的名称（“appname”_“modelname”,例如 blog_blogarticles）。

 当数据模型类写好之后，通过执行Django的数据迁移操作（python manage.py makemigrations，python manage.py migrate）就能够创建相应的数据库表，用来保存网站项目的数据。需要修改数据库表的结构，只需要修改数据模型类，迁移数据就能够实现数据库结构的调整。