[Django]MVT模式的详解

关于 Django 数据驱动 Web 应用的总体设计

把数据存取逻辑、业务逻辑和表现逻辑组合在一起的概念有时被称为软件架构的 Model-View-Controller (MVC)模式。在这个模式中， Model 代表数据存取层，View 代表的是系统中选择显示什么和怎么显示的部分，Controller 指的是系统中根据用户输入并视需要访问模型，以决定使用哪个视图的那部分。

为什么用缩写？

像 MVC 这样的明确定义模式的主要用于改善开发人员之间的沟通。比起告诉同事，“让我们采用抽象的数据存取方式，然后单独划分一层来显示数据，并且在中间加上一个控制它的层”，一个通用的说法会让你收益，你只需要说：“我们在这里使用MVC模式吧。

Django 紧紧地遵循这种 MVC 模式，可以称得上是一种 MVC 框架。以下是 Django 中 M、V 和 C 各自的含义：

M ，数据存取部分，由django数据库层处理，

V ，选择显示哪些数据要显示以及怎样显示的部分，由视图和模板处理。

C ，根据用户输入委派视图的部分，由 Django 框架根据 URLconf 设置，对给定 URL 调用适当的 Python 函数。

由于 C 由框架自行处理，而 Django 里更关注的是模型（Model）、模板(Template)和视图（Views），Django 也被称为 MTV 框架 。在 MTV 开发模式中：

M 代表模型（Model），即数据存取层。该层处理与数据相关的所有事务：如何存取、如何验证有效性、包含哪些行为以及数据之间的关系等。

T 代表模板(Template)，即表现层。该层处理与表现相关的决定：如何在页面或其他类型文档中进行显示。

V 代表视图（View），即业务逻辑层。该层包含存取模型及调取恰当模板的相关逻辑。你可以把它看作模型与模板之间的桥梁。

各种组件都是松耦合的，每个由 Django驱动的Web应用都有着明确的目的，并且可独立更改而不影响到其它的部分。

Django是怎么处理请求的？–url

在我们的视图功能之前，让我们暂停一下去了解更多一些有关Django是怎么工作的知识. 具体地说，当你通过在浏览器里敲http://127.0.0.1:8000/hello/来访问Hello world消息得时候，Django在后台有些什么动作呢？

所有均开始于setting文件。当你运行python manage.py runserver，脚本将在于manage.py同一个目录下查找名为setting.py的文件。这个文件包含了所有有关这个Django项目的配置信息，均大写： TEMPLATE_DIRS , DATABASE_NAME , 等. 最重要的设置：ROOT_URLCONF，它将作为URLconf告诉Django在这个站点中那些Python的模块将被用到

还记得什么时候django-admin.py startproject创建文件settings.py和urls.py吗？自动创建的settings.py包含一个ROOT_URLCONF配置用来指向自动产生的urls.py. 打开文件settings.py你将看到如下：

ROOT_URLCONF = ‘mysite.urls’
相对应的文件是mysite/urls.py

当访问 URL /hello/ 时，Django 根据 ROOT_URLCONF 的设置装载 URLconf 。然后按顺序逐个匹配URLconf里的URLpatterns，直到找到一个匹配的。当找到这个匹配的URLpatterns就调用相关联的view函数，并把 HttpRequest 对象作为第一个参数。（稍后再给出 HttpRequest 的更多信息）（我们将在后面看到HttpRequest的标准）

正如我们在第一个视图例子里面看到的，一个视图功能必须返回一个HttpResponse。一旦做完，Django将完成剩余的转换Python的对象到一个合适的带有HTTP头和body的Web Response，（例如，网页内容）。

总结一下：
进来的请求转入/hello/.

Django通过在ROOT_URLCONF配置来决定根URLconf.

Django在URLconf中的所有URL模式中，查找第一个匹配/hello/的条目。

如果找到匹配，将调用相应的视图函数

视图函数返回一个HttpResponse

Django转换HttpResponse为一个适合的HTTP response，以Web page显示出来

V—视图：

在使用django-admin startproject ** 创建完项目并使用manage.py创建apps后，

创建一个叫做views.py的空文件。这个Python模块将包含这一章的视图。请留意，Django对于view.py的文件命名没有特别的要求，它不在乎这个文件叫什么。但是根据约定，把它命名成view.py是个好主意，这样有利于其他开发者读懂你的代码

每个视图函数至少要有一个参数，通常被叫作request。这是一个触发这个视图、包含当前Web请求信息的对象，是类django.http.HttpRequest的一个实例。

因为我们的项目还对新建的视图一无所知。我们需要通过一个详细描述的URL来显式的告诉它并且激活这个视图。（继续我们刚才类似发布静态HTML文件的例子。现在我们已经创建了HTML文件，但还没有把它上传至服务器的目录。）为了绑定视图函数和URL，我们使用URLconf。

URLconf 就像是 Django 所支撑网站的目录。 它的本质是 URL 模式以及要为该 URL 模式调用的视图函数之间的映射表。你就是以这种方式告诉 Django，对于这个 URL 调用这段代码，对于那个 URL 调用那段代码。例如，当用户访问/foo/时，调用视图函数foo_view()，这个视图函数存在于Python模块文件view.py中。

当前应该注意是 urlpatterns 变量， Django 期望能从 ROOT_URLCONF 模块中找到它。该变量定义了 URL 以及用于处理这些 URL 的代码之间的映射关系。默认情况下，URLconf 所有内容都被注释起来了——Django 应用程序还是白版一块。

我们为urlpatterns加上一行： (‘^hello/$’, hello), 这行被称作URLpattern，它是一个Python的元组。元组中第一个元素是模式匹配字符串（正则表达式）；第二个元素是那个模式将使用的视图函数。
简单来说，我们只是告诉 Django，所有指向 URL /hello/ 的请求都应由 hello 这个视图函数来处理。

Django在检查URL模式前，移除每一个申请的URL开头的斜杠(/)。这意味着我们为/hello/写URL模式不用包含斜杠(/)。（刚开始，这样可能看起来不直观，但这样的要求简化了许多工作。

M–模型

DATABASE_ENGINE 告诉Django使用哪个数据库引擎。如果你在 Django 中使用数据库， DATABASE_ENGINE 必须是 Django中指定出的值
第一步是用Python代码来描述它们。打开由startapp 命令创建的models.py 并输入下面的内容：1

from django.db import modelsclass Publisher(models.Model):name = models.CharField(max_length=30)address = models.CharField(max_length=50)city = models.CharField(max_length=60)state_province = models.CharField(max_length=30)country = models.CharField(max_length=50)website = models.URLField()class Author(models.Model):first_name = models.CharField(max_length=30)last_name = models.CharField(max_length=40)email = models.EmailField()class Book(models.Model):title = models.CharField(max_length=100)authors = models.ManyToManyField(Author)publisher = models.ForeignKey(Publisher)publication_date = models.DateField()

“每个数据库表对应一个类”这条规则的例外情况是多对多关系。在我们的范例模型中， Book 有一个多对多字段叫做 authors 。该字段表明一本书籍有一个或多个作者，但 Book 数据库表却并没有 authors 字段。相反，Django创建了一个额外的表（多对多连接表）来处理书籍和作者之间的映射关系。

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

完成这些代码之后，现在让我们来在数据库中创建这些表。要完成该项工作，第一步是在 Django 项目中激活这些模型。将 books app 添加到配置文件的已安装应用列表中即可完成此步骤。再次编辑 settings.py 文件，找到 INSTALLED_APPS 设置。INSTALLED_APPS 告诉 Django 项目哪些 app 处于激活状态。

现在我们可以创建数据库表了。首先，用下面的命令验证模型的有效性：

python manage.py check
check命令检查你的模型的语法和逻辑是否正确。如果一切正常，你会看到 0 errors found 消息。如果出错，请检查你输入的模型代码。错误输出会给出非常有用的错误信息来帮助你修正你的模型。

模型确认没问题了，运行下面的命令来生成 CREATE TABLE 语句
python manage.py makemigration books
命令并没有在数据库中真正创建数据表，只是把SQL语句段打印出来，这样你可以看到Django究竟会做些什么

python manage.py migrate
命令是同步你的模型到数据库的一个简单方法。它会根据 INSTALLED_APPS 里设置的app来检查数据库，如果表不存在，它就会创建它。

一旦你创建了模型，Django自动为这些模型提供了高级的Python API

>>> from books.models import Publisher
>>> p1 = Publisher(name='Apress', address='2855 Telegraph Avenue',
...     city='Berkeley', state_province='CA', country='U.S.A.',
...     website='http://www.apress.com/')
>>> p1.save()
>>> p2 = Publisher(name="O'Reilly", address='10 Fawcett St.',
...     city='Cambridge', state_province='MA', country='U.S.A.',
...     website='http://www.oreilly.com/')
**当你使用Django modle API创建对象时Django并未将对象保存至数据库内，除非你调用`` save()`` 方法：**
>>> p2.save()
>如果需要一步完成对象的创建与存储至数据库，就使用`` objects.create()`` 方法。 下面的例子与之前的例子等价：
>p2 = Publisher.objects.create(name="O'Reilly",
...     address='10 Fawcett St.', city='Cambridge',
...     state_province='MA', country='U.S.A.',
...     website='http://www.oreilly.com/')
>>> publisher_list = Publisher.objects.all()
>>> publisher_list
[<Publisher: Publisher object>, <Publisher: Publisher object>]

当然，创建新的数据库，并更新之中的数据是必要的，但是，对于 Web 应用程序来说，更多的时候是在检索查询数据库。我们已经知道如何从一个给定的模型中取出所有记录：

Publisher.objects.all()
[<Publisher: Apress>, <Publisher: O’Reilly>]
这相当于这个SQL语句：

SELECT id, name, address, city, state_province, country, website
FROM books_publisher;
注意到Django在选择所有数据时并没有使用 SELECT* ，而是显式列出了所有字段。设计的时候就是这样： SELECT* 会更慢，而且最重要的是列出所有字段遵循了Python 界的一个信条：明言胜于暗示。

我们很少会一次性从数据库中取出所有的数据；通常都只针对一部分数据进行操作。在Django API中，我们可以使用filter() 方法对数据进行过滤：

Publisher.objects.filter(name=‘Apress’)
[<Publisher: Apress>]

上面的例子中filter() 函数返回一个记录集，这个记录集是一个列表。相对列表来说，有些时候我们更需要获取单个的对象， get() 方法就是在此时使用的：

Publisher.objects.get(name=“Apress”)
<Publisher: Apress>
这样，就返回了单个对象，而不是列表（更准确的说，QuerySet)。所以，如果结果是多个对象，会导致抛出异常

在运行前面的例子中，你可能已经注意到返回的结果是无序的。我们还没有告诉数据库怎样对结果进行排序，所以我们返回的结果是无序的。在你的 Django 应用中，你或许希望根据某字段的值对检索结果排序，比如说，按字母顺序。那么，使用 order_by() 这个方法就可以搞定了

Publisher.objects.filter(country=“U.S.A.”).order_by("-name")
[<Publisher: O’Reilly>, <Publisher: Apress>]
你应该没猜错，转换成SQL查询就是 WHERE 和 ORDER BY 的组合：

在“插入和更新数据”中，我们有提到模型的save()方法，这个方法会更新一行里的所有列。而某些情况下，我们只需要更新行里的某几列
在这个例子里我们可以看到Django的save()方法更新了不仅仅是name列的值，还有更新了所有的列。若name以外的列有可能会被其他的进程所改动的情况下，只更改name列显然是更加明智的。 更改某一指定的列，我们可以调用结果集（QuerySet）对象的update()方法：示例如下：

Publisher.objects.filter(id=52).update(name=‘Apress Publishing’)
update()方法对于任何结果集（QuerySet）均有效，这意味着你可以同时更新多条记录。

T–模板

创建一个Template 对象最简单的方法就是直接实例化它。Template 类就在 django.template 模块中，构造函数接受一个参数
一旦你创建一个 Template 对象，你可以用 context 来传递数据给它。一个context是一系列变量和它们值的集合。

context在Django里表现为 Context 类，在 django.template 模块里。她的构造函数带有一个可选的参数：一个字典映射变量和它们的值。调用 Template 对象的 render() 方法并传递context来填充模板

def search_book(request):return render(request,template_name='search_form.html')def current_datetime(request):now = datetime.datetime.now()t = Template("<html><body>It is now {{ current_date }}.</body></html>")html = t.render(Context({'current_date': now}))return HttpResponse(html)

模板系统能够非常简洁地处理更加复杂的数据结构，例如list、dictionary和自定义的对象。

在 Django 模板中遍历复杂数据结构的关键是句点字符 (.)。

同样，也可以通过句点来访问对象的属性。比方说， Python 的 datetime.date 对象有 year 、 month 和 day 几个属性，你同样可以在模板中使用句点来访问这些属性：

from django.template import Template, Context
import datetime
d = datetime.date(1993, 5, 2)
d.year
1993

d.month
5

d.day
2

t = Template(‘The month is {{ date.month }} and the year is {{ date.year }}.’)
c = Context({‘date’: d})
t.render©
u’The month is 5 and the year is 1993.’

为了减少模板加载调用过程及模板本身的冗余代码，Django 提供了一种使用方便且功能强大的 API ，用于从磁盘中加载模板，
要使用此模板加载API，首先你必须将模板的保存位置告诉框架。设置的保存文件就是我们前一章节讲述ROOT_URLCONF配置的时候提到的 settings.py。

打开你的settings.py配置文件，找到TEMPLATE_DIRS这项设置吧。它的默认设置是一个空元组（tuple），加上一些自动生成的注释。

TEMPLATE_DIRS = (
# Put strings here, like “/home/html/django_templates” or “C:/www/django/templates”.
# Always use forward slashes, even on Windows.
# Don’t forget to use absolute paths, not relative paths.
)
该设置告诉 Django 的模板加载机制在哪里查找模板。选择一个目录用于存放模板并将其添加到 TEMPLATE_DIRS 中：

TEMPLATE_DIRS = (
‘/home/django/mysite/templates’,
)
最省事的方式是使用绝对路径（即从文件系统根目录开始的目录路径）。如果想要更灵活一点并减少一些负面干扰，可利用 Django 配置文件就是 Python 代码这一点来动态构建 TEMPLATE_DIRS 的内容，如：例如：

import os.path

TEMPLATE_DIRS = (
os.path.join(os.path.dirname(file), ‘templates’).replace(’\’,’/’),
)

这个模板语言来源于World Online的开发经验和Django创造者们集体智慧的结晶。下面是关于它的一些设计哲学理念：

业务逻辑应该和表现逻辑相对分开 。我们将模板系统视为控制表现及表现相关逻辑的工具，仅此而已。模板系统不应提供超出此基本目标的功能。
出于这个原因，在 Django 模板中是不可能直接调用 Python 代码的。所有的编程工作基本上都被局限于模板标签的能力范围。当然，是有可能写出自定义的模板标签来完成任意工作，但这些“超范围”的 Django 模板标签有意地不允许执行任何 Python 代码。1

语法不应受到 HTML/XML 的束缚 。尽管 Django 模板系统主要用于生成 HTML，它还是被有意地设计为可生成非 HTML 格式，如纯文本。一些其它的模板语言是基于 XML 的，将所有的模板逻辑置于 XML 标签与属性之中，而 Django 有意地避开了这种限制。强制要求使用有效 XML 编写模板将会引发大量的人为错误和难以理解的错误信息，而且使用 XML 引擎解析模板也会导致令人无法容忍的模板处理开销。

假定设计师精通 HTML 编码 。模板系统的设计意图并不是为了让模板一定能够很好地显示在 Dreamweaver 这样的所见即所得编辑器中。这种限制过于苛刻，而且会使得语法不能像目前这样的完美。 Django 要求模板创作人员对直接编辑 HTML 非常熟悉。2

假定设计师不是 Python 程序员 。模板系统开发人员认为：模板通常由设计师而非程序员来编写，因此不应被假定拥有Python开发知识。