在比较 Python 框架的系列文章的第三部分中，我们来了解 Tornado，它是为处理异步进程而构建的。在这个由四部分组成的系列文章的前两篇中，我们介绍了 Pyramid 和 Flask Web 框架。我们已经构建了两次相同的应用程序，看到了一个完整的 DIY 框架和包含了更多功能的框架之间的异同。现在让我们来看看另一个稍微不同的选择：Tornado 框架。Tornado 在很大程度上与 Flask 一样简单，但有一个主要区别：Tornado 是专门为处理异步进程而构建的。在我们本系列所构建的应用程序中，这种特殊的酱料（LCTT 译注：这里意思是 Tornado 的异步功能）在我们构建的 app 中并不是非常有用，但我们将看到在哪里可以使用它，以及它在更一般的情况下是如何工作的。让我们继续前两篇文章中模式，首先从处理设置和配置开始。Tornado 启动和配置如果你一直关注这个系列，那么第一步应该对你来说习以为常。$ mkdir tornado_todo $ cd tornado_todo $ pipenv install --python 3.6 $ pipenv shell (tornado-someHash) $ pipenv install tornado创建一个 setup.py 文件来安装我们的应用程序相关的东西：(tornado-someHash) $ touch setup.py # setup.py from setuptools import setup, find_packages requires = [ 'tornado', 'tornado-sqlalchemy', 'psycopg2', ] setup( name='tornado_todo', version='0.0', description='A To-Do List built with Tornado', author='<Your name>', author_email='<Your email>', keywords='web tornado', packages=find_packages(), install_requires=requires, entry_points={ 'console_scripts': [ 'serve_app = todo:main', ], }, )因为 Tornado 不需要任何外部配置，所以我们可以直接编写 Python 代码来让程序运行。让我们创建 todo 目录，并用需要的前几个文件填充它。todo/ __init__.py models.py views.py就像 Flask 和 Pyramid 一样，Tornado 也有一些基本配置，放在 __init__.py 中。从 tornado.web 中，我们将导入 Application 对象，它将处理路由和视图的连接，包括数据库（当我们谈到那里时再说）以及运行 Tornado 应用程序所需的其它额外设置。# __init__.py from tornado.web import Application def main(): """Construct and serve the tornado application.""" app = Application()像 Flask 一样，Tornado 主要是一个 DIY 框架。当构建我们的 app 时，我们必须设置该应用实例。因为 Tornado 用它自己的 HTTP 服务器来提供该应用，我们必须设置如何提供该应用。首先，在 tornado.options.define 中定义要监听的端口。然后我们实例化 Tornado 的 HTTPServer，将该 Application 对象的实例作为参数传递给它。# __init__.py from tornado.httpserver import HTTPServer from tornado.options import define, options from tornado.web import Application define('port', default=8888, help='port to listen on') def main(): """Construct and serve the tornado application.""" app = Application() http_server = HTTPServer(app) http_server.listen(options.port)当我们使用 define 函数时，我们最终会在 options 对象上创建属性。第一个参数位置的任何内容都将是属性的名称，分配给 default 关键字参数的内容将是该属性的值。例如，如果我们将属性命名为 potato 而不是 port，我们可以通过 options.potato 访问它的值。在 HTTPServer 上调用 listen 并不会启动服务器。我们必须再做一步，找一个可以监听请求并返回响应的工作应用程序，我们需要一个输入输出循环。幸运的是，Tornado 以 tornado.ioloop.IOLoop 的形式提供了开箱即用的功能。# __init__.py from tornado.httpserver import HTTPServer from tornado.ioloop import IOLoop from tornado.options import define, options from tornado.web import Application define('port', default=8888, help='port to listen on') def main(): """Construct and serve the tornado application.""" app = Application() http_server = HTTPServer(app) http_server.listen(options.port) print('Listening on http://localhost:%i' % options.port) IOLoop.current().start()我喜欢某种形式的 print 语句，来告诉我什么时候应用程序正在提供服务，这是我的习惯。如果你愿意，可以不使用 print。我们以 IOLoop.current().start() 开始我们的 I/O 循环。让我们进一步讨论输入，输出和异步性。Python 中的异步和 I/O 循环的基础知识请允许我提前说明，我绝对，肯定，一定并且放心地说不是异步编程方面的专家。就像我写的所有内容一样，接下来的内容源于我对这个概念的理解的局限性。因为我是人，可能有很深很深的缺陷。异步程序的主要问题是：* 数据如何进来？ * 数据如何出去？ * 什么时候可以在不占用我全部注意力情况下运行某个过程？由于全局解释器锁（GIL），Python 被设计为一种单线程)语言。对于 Python 程序必须执行的每个任务，其线程执行的全部注意力都集中在该任务的持续时间内。我们的 HTTP 服务器是用 Python 编写的，因此，当接收到数据（如 HTTP 请求）时，服务器的唯一关心的是传入的数据。这意味着，在大多数情况下，无论是程序需要运行还是处理数据，程序都将完全消耗服务器的执行线程，阻止接收其它可能的数据，直到服务器完成它需要做的事情。在许多情况下，这不是太成问题。典型的 Web 请求，响应周期只需要几分之一秒。除此之外，构建 HTTP 服务器的套接字可以维护待处理的传入请求的积压。因此，如果请求在该套接字处理其它内容时进入，则它很可能只是在处理之前稍微排队等待一会。对于低到中等流量的站点，几分之一秒的时间并不是什么大问题，你可以使用多个部署的实例以及 NGINX 等负载均衡器来为更大的请求负载分配流量。但是，如果你的平均响应时间超过一秒钟，该怎么办？如果你使用来自传入请求的数据来启动一些长时间的过程（如机器学习算法或某些海量数据库查询），该怎么办？现在，你的单线程 Web 服务器开始累积一个无法寻址的积压请求，其中一些请求会因为超时而被丢弃。这不是一种选择，特别是如果你希望你的服务在一段时间内是可靠的。异步 Python 程序登场。重要的是要记住因为它是用 Python 编写的，所以程序仍然是一个单线程进程。除非特别标记，否则在异步程序中仍然会阻塞执行。但是，当异步程序结构正确时，只要你指定某个函数应该具有这样的能力，你的异步 Python 程序就可以“搁置”长时间运行的任务。然后，当搁置的任务完成并准备好恢复时，异步控制器会收到报告，只要在需要时管理它们的执行，而不会完全阻塞对新输入的处理。这有点夸张，所以让我们用一个人类的例子来证明。带回家吧我经常发现自己在家里试图完成很多家务，但没有多少时间来做它们。在某一天，积压的家务可能看起来像：* 做饭（20 分钟准备，40 分钟烹饪） * 洗碗（60 分钟） * 洗涤并擦干衣物（30 分钟洗涤，每次干燥 90 分钟） * 真空清洗地板（30 分钟）如果我是一个传统的同步程序，我会亲自完成每项任务。在我考虑处理任何其他事情之前，每项任务都需要我全神贯注地完成。因为如果没有我的全力关注，什么事情都完成不了。所以我的执行顺序可能如下：1. 完全专注于准备和烹饪食物，包括等待食物烹饪（60 分钟） 2. 将脏盘子移到水槽中（65 分钟过去了） 3. 清洗所有盘子（125 分钟过去了） 4. 开始完全专注于洗衣服，包括等待洗衣机洗完，然后将衣物转移到烘干机，再等烘干机完成（ 250 分钟过去了） 5. 对地板进行真空吸尘（280 分钟了）从头到尾完成所有事情花费了 4 小时 40 分钟。我应该像异步程序一样聪明地工作，而不是努力工作。我的家里到处都是可以为我工作的机器，而不用我一直努力工作。同时，现在我可以将注意力转移真正需要的东西上。我的执行顺序可能看起来像：1. 将衣物放入洗衣机并启动它（5 分钟） 2. 在洗衣机运行时，准备食物（25 分钟过去了） 3. 准备好食物后，开始烹饪食物（30 分钟过去了） 4. 在烹饪食物时，将衣物从洗衣机移到烘干机机中开始烘干（35 分钟过去了） 5. 当烘干机运行中，且食物仍在烹饪时，对地板进行真空吸尘（65 分钟过去了） 6. 吸尘后，将食物从炉子中取出并装盘子入洗碗机（70 分钟过去了） 7. 运行洗碗机（130 分钟完成）现在花费的时间下降到 2 小时 10 分钟。即使我允许在作业之间切换花费更多时间（总共 10-20 分钟）。如果我等待着按顺序执行每项任务，我花费的时间仍然只有一半左右。这就是将程序构造为异步的强大功能。那么 I/O 循环在哪里？一个异步 Python 程序的工作方式是从某个外部源（输入）获取数据，如果某个进程需要，则将该数据转移到某个外部工作者（输出）进行处理。当外部进程完成时，Python 主程序会收到提醒，然后程序获取外部处理（输入）的结果，并继续这样其乐融融的方式。当数据不在 Python 主程序手中时，主程序就会被释放来处理其它任何事情。包括等待全新的输入（如 HTTP 请求）和处理长时间运行的进程的结果（如机器学习算法的结果，长时间运行的数据库查询）。主程序虽仍然是单线程的，但成了事件驱动的，它对程序处理的特定事件会触发动作。监听这些事件并指示应如何处理它们的主要是 I/O 循环在工作。我知道，我们走了很长的路才得到这个重要的解释，但我希望在这里传达的是，它不是魔术，也不是某种复杂的并行处理或多线程工作。全局解释器锁仍然存在，主程序中任何长时间运行的进程仍然会阻塞其它任何事情的进行，该程序仍然是单线程的。然而，通过将繁琐的工作外部化，我们可以将线程的注意力集中在它需要注意的地方。这有点像我上面的异步任务。当我的注意力完全集中在准备食物上时，它就是我所能做的一切。然而，当我能让炉子帮我做饭，洗碗机帮我洗碗，洗衣机和烘干机帮我洗衣服时，我的注意力就会被释放出来，去做其它事情。当我被提醒，我的一个长时间运行的任务已经完成并准备再次处理时，如果我的注意力是空闲的，我可以获取该任务的结果，并对其做下一步需要做的任何事情。Tornado 路由和视图尽管经历了在 Python 中讨论异步的所有麻烦，我们还是决定暂不使用它。先来编写一个基本的 Tornado 视图。与我们在 Flask 和 Pyramid 实现中看到的基于函数的视图不同，Tornado 的视图都是基于类的。这意味着我们将不在使用单独的、独立的函数来规定如何处理请求。相反，传入的 HTTP 请求将被捕获并将其分配为我们定义的类的一个属性。然后，它的方法将处理相应的请求类型。让我们从一个基本的视图开始，即在屏幕上打印 “Hello, World”。我们为 Tornado 应用程序构造的每个基于类的视图都必须继承 tornado.web 中的 RequestHandler 对象。这将设置我们需要（但不想写）的所有底层逻辑来接收请求，同时构造正确格式的 HTTP 响应。from tornado.web import RequestHandler class HelloWorld(RequestHandler): """Print 'Hello, world!' as the response body.""" def get(self): """Handle a GET request for saying Hello World!.""" self.write("Hello, world!")因为我们要处理 GET 请求，所以我们声明（实际上是重写）了 get 方法。我们提供文本或 JSON 可序列化对象，用 self.write 写入响应体。之后，我们让 RequestHandler 来做在发送响应之前必须完成的其它工作。就目前而言，此视图与 Tornado 应用程序本身并没有实际连接。我们必须回到 __init__.py，并稍微更新 main 函数。以下是新的内容：# __init__.py from tornado.httpserver import HTTPServer from tornado.ioloop import IOLoop from tornado.options import define, options from tornado.web import Application from todo.views import HelloWorld define('port', default=8888, help='port to listen on') def main(): """Construct and serve the tornado application.""" app = Application([ ('/', HelloWorld) ]) http_server = HTTPServer(app) http_server.listen(options.port) print('Listening on http://localhost:%i' % options.port) IOLoop.current().start()我们做了什么我们将 views.py 文件中的 HelloWorld 视图导入到脚本 __init__.py 的顶部。然后我们添加了一个路由-视图对应的列表，作为 Application 实例化的第一个参数。每当我们想要在应用程序中声明一个路由时，它必须绑定到一个视图。如果需要，可以对多个路由使用相同的视图，但每个路由必须有一个视图。我们可以通过在 setup.py 中启用的 serve_app 命令来运行应用程序，从而确保这一切都能正常工作。查看 http://localhost:8888/ 并看到它显示 “Hello, world!”。当然，在这个领域中我们还能做更多，也将做更多，但现在让我们来讨论模型吧。连接数据库如果我们想要保留数据，就需要连接数据库。与 Flask 一样，我们将使用一个特定于框架的 SQLAchemy 变体，名为 tornado-sqlalchemy。为什么要使用它而不是 SQLAlchemy 呢？好吧，其实 tornado-sqlalchemy 具有简单 SQLAlchemy 的所有优点，因此我们仍然可以使用通用的 Base 声明模型，并使用我们习以为常的所有列数据类型和关系。除了我们已经惯常了解到的，tornado-sqlalchemy 还为其数据库查询功能提供了一种可访问的异步模式，专门用于与 Tornado 现有的 I/O 循环一起工作。我们通过将 tornado-sqlalchemy 和 psycopg2 添加到 setup.py 到所需包的列表并重新安装包来创建环境。在 models.py 中，我们声明了模型。这一步看起来与我们在 Flask 和 Pyramid 中已经看到的完全一样，所以我将跳过全部声明，只列出了 Task 模型的必要部分。# 这不是完整的 models.py, 但是足够看到不同点 from tornado_sqlalchemy import declarative_base Base = declarative_base class Task(Base): # 等等，因为剩下的几乎所有的东西都一样 ...我们仍然需要将 tornado-sqlalchemy 连接到实际应用程序。在 __init__.py 中，我们将定义数据库并将其集成到应用程序中。# __init__.py from tornado.httpserver import HTTPServer from tornado.ioloop import IOLoop from tornado.options import define, options from tornado.web import Application from todo.views import HelloWorld # add these import os from tornado_sqlalchemy import make_session_factory define('port', default=8888, help='port to listen on') factory = make_session_factory(os.environ.get('DATABASE_URL', '')) def main(): """Construct and serve the tornado application.""" app = Application([ ('/', HelloWorld) ], session_factory=factory ) http_server = HTTPServer(app) http_server.listen(options.port) print('Listening on http://localhost:%i' % options.port) IOLoop.current().start()就像我们在 Pyramid 中传递的会话工厂一样，我们可以使用 make_session_factory 来接收数据库 URL 并生成一个对象，这个对象的唯一目的是为视图提供到数据库的连接。然后我们将新创建的 factory 传递给 Application 对象，并使用 session_factory 关键字参数将它绑定到应用程序中。最后，初始化和管理数据库与 Flask 和 Pyramid 相同（即，单独的 DB 管理脚本，与 Base 对象一起工作等）。它看起来很相似，所以在这里我就不介绍了。回顾视图Hello，World 总是适合学习基础知识，但我们需要一些真实的，特定应用程序的视图。让我们从 info 视图开始。# views.py import json from tornado.web import RequestHandler class InfoView(RequestHandler): """只允许 GET 请求""" SUPPORTED_METHODS = ["GET"] def set_default_headers(self): """设置默认响应头为 json 格式的""" self.set_header("Content-Type", 'application/json; charset="utf-8"') def get(self): """列出这个 API 的路由""" routes = { 'info': 'GET /api/v1', 'register': 'POST /api/v1/accounts', 'single profile detail': 'GET /api/v1/accounts/<username>', 'edit profile': 'PUT /api/v1/accounts/<username>', 'delete profile': 'DELETE /api/v1/accounts/<username>', 'login': 'POST /api/v1/accounts/login', 'logout': 'GET /api/v1/accounts/logout', "user's tasks": 'GET /api/v1/accounts/<username>/tasks', "create task": 'POST /api/v1/accounts/<username>/tasks', "task detail": 'GET /api/v1/accounts/<username>/tasks/<id>', "task update": 'PUT /api/v1/accounts/<username>/tasks/<id>', "delete task": 'DELETE /api/v1/accounts/<username>/tasks/<id>' } self.write(json.dumps(routes))有什么改变吗？让我们从上往下看。我们添加了 SUPPORTED_METHODS 类属性，它是一个可迭代对象，代表这个视图所接受的请求方法，其他任何方法都将返回一个 405 状态码。当我们创建 HelloWorld 视图时，我们没有指定它，主要是当时有点懒。如果没有这个类属性，此视图将响应任何试图绑定到该视图的路由的请求。我们声明了 set_default_headers 方法，它设置 HTTP 响应的默认头。我们在这里声明它，以确保我们返回的任何响应都有一个 "Content-Type" 是 "application/json" 类型。我们将 json.dumps(some_object) 添加到 self.write 的参数中，因为它可以很容易地构建响应主体的内容。现在已经完成了，我们可以继续将它连接到 __init__.py 中的主路由。# __init__.py from tornado.httpserver import HTTPServer from tornado.ioloop import IOLoop from tornado.options import define, options from tornado.web import Application from todo.views import InfoView # 添加这些 import os from tornado_sqlalchemy import make_session_factory define('port', default=8888, help='port to listen on') factory = make_session_factory(os.environ.get('DATABASE_URL', '')) def main(): """Construct and serve the tornado application.""" app = Application([ ('/', InfoView) ], session_factory=factory ) http_server = HTTPServer(app) http_server.listen(options.port) print('Listening on http://localhost:%i' % options.port) IOLoop.current().start()我们知道，还需要编写更多的视图和路由。每个都会根据需要放入 Application 路由列表中，每个视图还需要一个 set_default_headers 方法。在此基础上，我们还将创建 send_response 方法，它的作用是将响应与我们想要给响应设置的任何自定义状态码打包在一起。由于每个视图都需要这两个方法，因此我们可以创建一个包含它们的基类，这样每个视图都可以继承基类。这样，我们只需要编写一次。# views.py import json from tornado.web import RequestHandler class BaseView(RequestHandler): """Base view for this application.""" def set_default_headers(self): """Set the default response header to be JSON.""" self.set_header("Content-Type", 'application/json; charset="utf-8"') def send_response(self, data, status=200): """Construct and send a JSON response with appropriate status code.""" self.set_status(status) self.write(json.dumps(data))对于我们即将编写的 TaskListView 这样的视图，我们还需要一个到数据库的连接。我们需要 tornado_sqlalchemy 中的 SessionMixin 在每个视图类中添加一个数据库会话。我们可以将它放在 BaseView 中，这样，默认情况下，从它继承的每个视图都可以访问数据库会话。# views.py import json from tornado_sqlalchemy import SessionMixin from tornado.web import RequestHandler class BaseView(RequestHandler, SessionMixin): """Base view for this application.""" def set_default_headers(self): """Set the default response header to be JSON.""" self.set_header("Content-Type", 'application/json; charset="utf-8"') def send_response(self, data, status=200): """Construct and send a JSON response with appropriate status code.""" self.set_status(status) self.write(json.dumps(data))只要我们修改 BaseView 对象，在将数据发布到这个 API 时，我们就应该定位到这里。当 Tornado（从 v.4.5 开始）使用来自客户端的数据并将其组织起来到应用程序中使用时，它会将所有传入数据视为字节串。但是，这里的所有代码都假设使用 Python 3，因此我们希望使用的唯一字符串是 Unicode 字符串。我们可以为这个 BaseView 类添加另一个方法，它的工作是将输入数据转换为 Unicode，然后再在视图的其他地方使用。如果我们想要在正确的视图方法中使用它之前转换这些数据，我们可以重写视图类的原生 prepare 方法。它的工作是在视图方法运行前运行。如果我们重写 prepare 方法，我们可以设置一些逻辑来运行，每当收到请求时，这些逻辑就会执行字节串到 Unicode 的转换。# views.py import json from tornado_sqlalchemy import SessionMixin from tornado.web import RequestHandler class BaseView(RequestHandler, SessionMixin): """Base view for this application.""" def prepare(self): self.form_data = { key: [val.decode('utf8') for val in val_list] for key, val_list in self.request.arguments.items() } def set_default_headers(self): """Set the default response header to be JSON.""" self.set_header("Content-Type", 'application/json; charset="utf-8"') def send_response(self, data, status=200): """Construct and send a JSON response with appropriate status code.""" self.set_status(status) self.write(json.dumps(data))如果有任何数据进入，它将在 self.request.arguments 字典中找到。我们可以通过键访问该数据库，并将其内容（始终是列表）转换为 Unicode。因为这是基于类的视图而不是基于函数的，所以我们可以将修改后的数据存储为一个实例属性，以便以后使用。我在这里称它为 form_data，但它也可以被称为 potato。关键是我们可以存储提交给应用程序的数据。异步视图方法现在我们已经构建了 BaseaView，我们可以构建 TaskListView 了，它会继承 BaseaView。正如你可以从章节标题中看到的那样，以下是所有关于异步性的讨论。TaskListView 将处理返回任务列表的 GET 请求和用户给定一些表单数据来创建新任务的 POST 请求。让我们首先来看看处理 GET 请求的代码。# all the previous imports import datetime from tornado.gen import coroutine from tornado_sqlalchemy import as_future from todo.models import Profile, Task # the BaseView is above here class TaskListView(BaseView): """View for reading and adding new tasks.""" SUPPORTED_METHODS = ("GET", "POST",) @coroutine def get(self, username): """Get all tasks for an existing user.""" with self.make_session() as session: profile = yield as_future(session.query(Profile).filter(Profile.username == username).first) if profile: tasks = [task.to_dict() for task in profile.tasks] self.send_response({ 'username': profile.username, 'tasks': tasks })这里的第一个主要部分是 @coroutine 装饰器，它从 tornado.gen 导入。任何具有与调用堆栈的正常流程不同步的 Python 可调用部分实际上是“协程”，即一个可以与其它协程一起运行的协程。在我的家务劳动的例子中，几乎所有的家务活都是一个共同的例行协程。有些阻止了例行协程（例如，给地板吸尘），但这种例行协程只会阻碍我开始或关心其它任何事情的能力。它没有阻止已经启动的任何其他协程继续进行。Tornado 提供了许多方法来构建一个利用协程的应用程序，包括允许我们设置函数调用锁，同步异步协程的条件，以及手动修改控制 I/O 循环的事件系统。这里使用 @coroutine 装饰器的唯一条件是允许 get 方法将 SQL 查询作为后台进程，并在查询完成后恢复，同时不阻止 Tornado I/O 循环去处理其他传入的数据源。这就是关于此实现的所有“异步”：带外数据库查询。显然，如果我们想要展示异步 Web 应用程序的魔力和神奇，那么一个任务列表就不是好的展示方式。但是，这就是我们正在构建的，所以让我们来看看方法如何利用 @coroutine 装饰器。SessionMixin 混合到 BaseView 声明中，为我们的视图类添加了两个方便的，支持数据库的属性：session 和 make_session。它们的名字相似，实现的目标也相当相似。self.session 属性是一个关注数据库的会话。在请求-响应周期结束时，在视图将响应发送回客户端之前，任何对数据库的更改都被提交，并关闭会话。self.make_session 是一个上下文管理器和生成器，可以动态构建和返回一个全新的会话对象。第一个 self.session 对象仍然存在。无论如何，反正 make_session 会创建一个新的。make_session 生成器还为其自身提供了一个功能，用于在其上下文（即缩进级别）结束时提交和关闭它创建的会话。如果你查看源代码，则赋值给 self.session 的对象类型与 self.make_session 生成的对象类型之间没有区别，不同之处在于它们是如何被管理的。使用 make_session 上下文管理器，生成的会话仅属于上下文，在该上下文中开始和结束。你可以使用 make_session 上下文管理器在同一个视图中打开，修改，提交以及关闭多个数据库会话。self.session 要简单得多，当你进入视图方法时会话已经打开，在响应被发送回客户端之前会话就已提交。虽然读取文档片段和 PyPI 示例都说明了上下文管理器的使用，但是没有说明 self.session 对象或由 self.make_session 生成的 session 本质上是不是异步的。当我们启动查询时，我们开始考虑内置于 tornado-sqlalchemy 中的异步行为。tornado-sqlalchemy 包为我们提供了 as_future 函数。它的工作是装饰 tornado-sqlalchemy 会话构造的查询并 yield 其返回值。如果视图方法用 @coroutine 装饰，那么使用 yield as_future(query) 模式将使封装的查询成为一个异步后台进程。I/O 循环会接管等待查询的返回值和 as_future 创建的 future 对象的解析。要访问 as_future（query） 的结果，你必须从它 yield。否则，你只能获得一个未解析的生成器对象，并且无法对查询执行任何操作。这个视图方法中的其他所有内容都与之前课堂上的类似，与我们在 Flask 和 Pyramid 中看到的内容类似。post 方法看起来非常相似。为了保持一致性，让我们看一下 post 方法以及它如何处理用 BaseView 构造的 self.form_data。@coroutine def post(self, username): """Create a new task.""" with self.make_session() as session: profile = yield as_future(session.query(Profile).filter(Profile.username == username).first) if profile: due_date = self.form_data['due_date'][0] task = Task( name=self.form_data['name'][0], note=self.form_data['note'][0], creation_date=datetime.now(), due_date=datetime.strptime(due_date, '%d/%m/%Y %H:%M:%S') if due_date else None, completed=self.form_data['completed'][0], profile_id=profile.id, profile=profile ) session.add(task) self.send_response({'msg': 'posted'}, status=201)正如我所说，这是我们所期望的：* 与我们在 get 方法中看到的查询模式相同 * 构造一个新的 Task 对象的实例，用 form_data 的数据填充 * 添加新的 Task 对象（但不提交，因为它由上下文管理器处理！）到数据库会话 * 将响应发送给客户端这样我们就有了 Tornado web 应用程序的基础。其他内容（例如，数据库管理和更多完整应用程序的视图）实际上与我们在 Flask 和 Pyramid 应用程序中看到的相同。关于使用合适的工具完成合适的工作的一点想法在我们继续浏览这些 Web 框架时，我们开始看到它们都可以有效地处理相同的问题。对于像这样的待办事项列表，任何框架都可以完成这项任务。但是，有些 Web 框架比其它框架更适合某些工作，这具体取决于对你来说什么“更合适”和你的需求。虽然 Tornado 显然和 Pyramid 或 Flask 一样可以处理相同工作，但将它用于这样的应用程序实际上是一种浪费，这就像开车从家走一个街区（LCTT 译注：这里意思应该是从家开始走一个街区只需步行即可）。是的，它可以完成“旅行”的工作，但短途旅行不是你选择汽车而不是自行车或者使用双脚的原因。根据文档，Tornado 被称为 “Python Web 框架和异步网络库”。在 Python Web 框架生态系统中很少有人喜欢它。如果你尝试完成的工作需要（或将从中获益）以任何方式、形状或形式的异步性，使用 Tornado。如果你的应用程序需要处理多个长期连接，同时又不想牺牲太多性能，选择 Tornado。如果你的应用程序是多个应用程序，并且需要线程感知以准确处理数据，使用 Tornado。这是它最有效的地方。用你的汽车做“汽车的事情”，使用其他交通工具做其他事情。向前看，进行一些深度检查谈到使用合适的工具来完成合适的工作，在选择框架时，请记住应用程序的范围和规模，包括现在和未来。到目前为止，我们只研究了适用于中小型 Web 应用程序的框架。本系列的下一篇也是最后一篇将介绍最受欢迎的 Python 框架之一 Django，它适用于可能会变得更大的大型应用程序。同样，尽管它在技术上能够并且将会处理待办事项列表问题，但请记住，这不是它的真正用途。我们仍然会通过它来展示如何使用它来构建应用程序，但我们必须牢记框架的意图以及它是如何反映在架构中的：Flask： 适用于小型，简单的项目。它可以使我们轻松地构建视图并将它们快速连接到路由，它可以简单地封装在一个文件中。Pyramid： 适用于可能增长的项目。它包含一些配置来启动和运行。应用程序组件的独立领域可以很容易地划分并构建到任意深度，而不会忽略中央应用程序。Tornado： 适用于受益于精确和有意识的 I/O 控制的项目。它允许协程，并轻松公开可以控制如何接收请求或发送响应以及何时发生这些操作的方法。Django：（我们将会看到）意味着可能会变得更大的东西。它有着非常庞大的生态系统，包括大量插件和模块。它非常有主见的配置和管理，以保持所有不同部分在同一条线上。无论你是从本系列的第一篇文章开始阅读，还是稍后才加入的，都要感谢阅读！请随意留下问题或意见。下次再见时，我手里会拿着 Django。感谢 Python BDFL我必须把功劳归于它应得的地方，非常感谢 Guido van Rossum，不仅仅是因为他创造了我最喜欢的编程语言。在 PyCascades 2018 期间，我很幸运的不仅做了基于这个文章系列的演讲，而且还被邀请参加了演讲者的晚宴。整个晚上我都坐在 Guido 旁边，不停地问他问题。其中一个问题是，在 Python 中异步到底是如何工作的，但他没有一点大惊小怪，而是花时间向我解释，让我开始理解这个概念。他后来推特给我发了一条消息：是用于学习异步 Python 的广阔资源。我随后在三个月内阅读了三次，然后写了这篇文章。你真是一个非常棒的人，Guido！via: https://opensource.com/article/18/6/tornado-framework作者：Nicholas Hunt-Walker 选题：lujun9972 译者：MjSeven 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
在这个比较 Python 框架的最后一篇中，让我们看看 Django。在本系列（由四部分组成）的前三篇文章中，我们讨论了 Pyramid、Flask 和 Tornado 这 3 个 Web 框架。我们已经构建了三次相同的应用程序，最终我们遇到了 Django。总的来说，Django 是目前 Python 开发人员使用的主要 Web 框架，并且原因显而易见。它擅长隐藏大量的配置逻辑，让你专注于能够快速构建大型应用程序。也就是说，当涉及到小型项目时，比如我们的待办事项列表应用程序，Django 可能有点像用消防水管来进行水枪大战。让我们来看看它们是如何结合在一起的。关于 DjangoDjango 将自己定位为“一个鼓励快速开发和整洁、实用的设计的高级 Python Web 框架。它由经验丰富的开发人员构建，解决了 Web 开发的很多麻烦，因此你可以专注于编写应用程序而无需重新发明轮子”。而且它确实做到了！这个庞大的 Web 框架附带了非常多的工具，以至于在开发过程中，如何将所有内容组合在一起协同工作可能是个谜。除了框架本身很大，Django 社区也是非常庞大的。事实上，它非常庞大和活跃，以至于有一个网站专门用于为人们收集第三方包，这些第三方包可集成进 Django 来做一大堆事情。包括从身份验证和授权到完全基于 Django 的内容管理系统，电子商务附加组件以及与 Stripe（LCTT 译注：美版“支付宝”）集成的所有内容。至于不要重新发明轮子：如果你想用 Django 完成一些事情，有人可能已经做过了，你只需将它集成进你的项目就行。为此，我们希望使用 Django 构建 REST API，因此我们将使用流行的 Django REST 框架。它的工作是将 Django 框架（Django 使用自己的模板引擎构建 HTML 页面）转换为专门用于有效地处理 REST 交互的系统。让我们开始吧。Django 启动和配置$ mkdir django_todo $ cd django_todo $ pipenv install --python 3.6 $ pipenv shell (django-someHash) $ pipenv install django djangorestframework作为参考，我们使用的是 django-2.0.7 和 djangorestframework-3.8.2。与 Flask, Tornado 和 Pyramid 不同，我们不需要自己编写 setup.py 文件，我们并不是在做一个可安装的 Python 发布版。像很多事情一样，Django 以自己的方式处理这个问题。我们仍然需要一个 requirements.txt 文件来跟踪我们在其它地方部署的所有必要安装。但是，就 Django 项目中的目标模块而言，Django 会让我们列出我们想要访问的子目录，然后允许我们从这些目录中导入，就像它们是已安装的包一样。首先，我们必须创建一个 Django 项目。当我们安装了 Django 后，我们还安装了命令行脚本 django-admin。它的工作是管理所有与 Django 相关的命令，这些命令有助于我们将项目整合在一起，并在我们继续开发的过程中对其进行维护。django-admin 并不是让我们从头开始构建整个 Django 生态系统，而是让我们从标准 Django 项目所需的所有必要文件（以及更多）的基础上开始。调用 django-admin 的 start-project 命令的语法是 django-admin startproject <项目名称> <存放目录>。我们希望文件存于当前的工作目录中，所以：(django-someHash) $ django-admin startproject django_todo .输入 ls 将显示一个新文件和一个新目录。(django-someHash) $ ls manage.py django_todomanage.py 是一个可执行命令行 Python 文件，它最终成为 django-admin 的封装。因此，它的工作与 django-admin 是一样的：帮助我们管理项目。因此得名 manage.py。它在 django_todo 目录里创建了一个新目录 django_todo，其代表了我们项目的配置根目录。现在让我们深入研究一下。配置 Django可以将 django_todo 目录称为“配置根目录”，我们的意思是这个目录包含了通常配置 Django 项目所需的文件。几乎所有这个目录之外的内容都只关注与项目模型、视图、路由等相关的“业务逻辑”。所有连接项目的点都将在这里出现。在 django_todo 目录中调用 ls 会显示以下四个文件：(django-someHash) $ cd django_todo (django-someHash) $ ls __init__.py settings.py urls.py wsgi.py__init__.py 文件为空，之所以存在是为了将此目录转换为可导入的 Python 包。settings.py 是设置大多数配置项的地方。例如项目是否处于 DEBUG 模式，正在使用哪些数据库，Django 应该定位文件的位置等等。它是配置根目录的“主要配置”部分，我们将在一会深入研究。urls.py 顾名思义就是设置 URL 的地方。虽然我们不必在此文件中显式写入项目的每个 URL，但我们需要让此文件知道在其他任何地方已声明的 URL。如果此文件未指向其它 URL，则那些 URL 就不存在。wsgi.py 用于在生产环境中提供应用程序。就像 Pyramid、 Tornado 和 Flask 暴露了一些 “app” 对象一样，它们用来提供配置好的应用程序，Django 也必须暴露一个，就是在这里完成的。它可以和 Gunicorn、Waitress 或者 uWSGI 一起配合来提供服务。设置 settings看一看 settings.py，它里面有大量的配置项，那些只是默认值！这甚至不包括数据库、静态文件、媒体文件、任何集成的钩子，或者可以配置 Django 项目的任何其它几种方式。让我们从上到下看看有什么：BASE_DIR 设置目录的绝对路径，或者是 manage.py 所在的目录。这对于定位文件非常有用。SECRET_KEY 是用于 Django 项目中加密签名的密钥。在实际中，它用于会话、cookie、CSRF 保护和身份验证令牌等。最好在第一次提交之前，尽快应该更改 SECRET_KEY 的值并将其放置到环境变量中。DEBUG 告诉 Django 是以开发模式还是生产模式运行项目。这是一个非常关键的区别。在开发模式下，当弹出一个错误时，Django 将显示导致错误的完整堆栈跟踪，以及运行项目所涉及的所有设置和配置。如果在生产环境中将 DEBUG 设置为 True，这可能成为一个巨大的安全问题。在生产模式下，当出现问题时，Django 会显示一个简单的错误页面，即除错误代码外不提供任何信息。保护我们项目的一个简单方法是将 DEBUG 设置为环境变量，如 bool(os.environ.get('DEBUG', ''))。ALLOWED_HOSTS 是应用程序提供服务的主机名的列表。在开发模式中，这可能是空的；但是在生产环境中，如果为项目提供服务的主机不在 ALLOWED_HOSTS 列表中，Django 项目将无法运行。这是设置为环境变量的另一种情况。INSTALLED_APPS 是我们的 Django 项目可以访问的 Django “apps” 列表（将它们视为子目录，稍后会详细介绍）。默认情况下，它将提供：内置的 Django 管理网站Django 的内置认证系统Django 的数据模型通用管理器会话管理Cookie 和基于会话的消息传递站点固有的静态文件的用法，比如 css 文件、js 文件、任何属于我们网站设计的图片等。MIDDLEWARE 顾名思义：帮助 Django 项目运行的中间件。其中很大一部分用于处理各种类型的安全，尽管我们可以根据需要添加其它中间件。ROOT_URLCONF 设置基本 URL 配置文件的导入路径。还记得我们之前见过的那个 urls.py 吗？默认情况下，Django 指向该文件以此来收集所有的 URL。如果我们想让 Django 在其它地方寻找，我们将在这里设置 URL 位置的导入路径。TEMPLATES 是 Django 用于我们网站前端的模板引擎列表，假如我们依靠 Django 来构建我们的 HTML。我们在这里不需要，那就无关紧要了。WSGI_APPLICATION 设置我们的 WSGI 应用程序的导入路径 —— 在生产环境下使用的东西。默认情况下，它指向 wsgi.py 中的 application 对象。这很少（如果有的话）需要修改。DATABASES 设置 Django 项目将访问那些数据库。必须设置 default 数据库。我们可以通过名称设置别的数据库，只要我们提供 HOST、USER、PASSWORD、PORT、数据库名称 NAME 和合适的 ENGINE。可以想象，这些都是敏感的信息，因此最好将它们隐藏在环境变量中。查看 Django 文档了解更多详情。注意：如果不是提供数据库的每个单个部分，而是提供完整的数据库 URL，请查看 djdatabaseurl。AUTH_PASSWORD_VALIDATORS 实际上是运行以检查输入密码的函数列表。默认情况下我们有一些，但是如果我们有其它更复杂的验证需求：不仅仅是检查密码是否与用户的属性匹配，是否超过最小长度，是否是 1000 个最常用的密码之一，或者密码完全是数字，我们可以在这里列出它们。LANGUAGE_CODE 设置网站的语言。默认情况下它是美国英语，但我们可以将其切换为其它语言。TIME_ZONE 是我们 Django 项目后中自动生成的时间戳的时区。我强调坚持使用 UTC 并在其它地方执行任何特定于时区的处理，而不是尝试重新配置此设置。正如这篇文章 所述，UTC 是所有时区的共同点，因为不需要担心偏移。如果偏移很重要，我们可以根据需要使用与 UTC 的适当偏移来计算它们。USE_I18N 将让 Django 使用自己的翻译服务来为前端翻译字符串。I18N = 国际化（internationalization，“i” 和 “n” 之间共 18 个字符）。USE_L10N L10N = 本地化（localization，在 l 和 n 之间共 10 个字符) 。如果设置为 True，那么将使用数据的公共本地格式。一个很好的例子是日期：在美国它是 MM-DD-YYYY。在欧洲，日期往往写成 DD-MM-YYYY。STATIC_URL 是用于提供静态文件的主体部分。我们将构建一个 REST API，因此我们不需要考虑静态文件。通常，这会为每个静态文件的域名设置根路径。所以，如果我们有一个 Logo 图像，那就是 http://<domainname>/<STATIC_URL>/logo.gif。默认情况下，这些设置已准备就绪。我们必须改变的一个选项是 DATABASES 设置。首先，我们创建将要使用的数据库：(django-someHash) $ createdb django_todo我们想要像使用 Flask、Pyramid 和 Tornado 一样使用 PostgreSQL 数据库，这意味着我们必须更改 DATABASES 设置以允许我们的服务器访问 PostgreSQL 数据库。首先是引擎。默认情况下，数据库引擎是 django.db.backends.sqlite3，我们把它改成 django.db.backends.postgresql。有关 Django 可用引擎的更多信息，请查看文档。请注意，尽管技术上可以将 NoSQL 解决方案整合到 Django 项目中，但为了开箱即用，Django 强烈偏向于 SQL 解决方案。接下来，我们必须为连接参数的不同部分指定键值对。NAME 是我们刚刚创建的数据库的名称。USER 是 Postgres 数据库用户名。PASSWORD 是访问数据库所需的密码。HOST 是数据库的主机。当我们在本地开发时，localhost 或 127.0.0.1 都将起作用。PORT 是我们为 Postgres 开放的端口，它通常是 5432。settings.py 希望我们为每个键提供字符串值。但是，这是高度敏感的信息。任何负责任的开发人员都不应该这样做。有几种方法可以解决这个问题，一种是我们需要设置环境变量。DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql', 'NAME': os.environ.get('DB_NAME', ''), 'USER': os.environ.get('DB_USER', ''), 'PASSWORD': os.environ.get('DB_PASS', ''), 'HOST': os.environ.get('DB_HOST', ''), 'PORT': os.environ.get('DB_PORT', ''), } }在继续之前，请确保设置环境变量，否则 Django 将无法工作。此外，我们需要在此环境中安装 psycopg2，以便我们可以与数据库通信。Django 路由和视图让我们在这个项目中实现一些函数。我们将使用 Django REST 框架来构建 REST API，所以我们必须确保在 settings.py 中将 rest_framework 添加到 INSTALLED_APPS 的末尾。INSTALLED_APPS = [ 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'rest_framework' ]虽然 Django REST 框架并不专门需要基于类的视图（如 Tornado）来处理传入的请求，但类是编写视图的首选方法。让我们来定义一个类视图。让我们在 django_todo 创建一个名为 views.py 的文件。在 views.py 中，我们将创建 “Hello, world!” 视图。# in django_todo/views.py from rest_framework.response import JsonResponse from rest_framework.views import APIView class HelloWorld(APIView): def get(self, request, format=None): """Print 'Hello, world!' as the response body.""" return JsonResponse("Hello, world!")每个 Django REST 框架基于类的视图都直接或间接地继承自 APIView。APIView 处理大量的东西，但针对我们的用途，它做了以下特定的事情：* 根据 HTTP 方法（例如 GET、POST、PUT、DELETE）来设置引导对应请求所需的方法 * 用我们需要的所有数据和属性来填充 `request` 对象，以便解析和处理传入的请求 * 采用 `Response` 或 `JsonResponse`，每个调度方法（即名为 `get`、`post`、`put`、`delete` 的方法）返回并构造格式正确的 HTTP 响应。终于，我们有一个视图了！它本身没有任何作用，我们需要将它连接到路由。如果我们跳转到 django_todo/urls.py，我们会到达默认的 URL 配置文件。如前所述：如果 Django 项目中的路由不包含在此处，则它不存在。我们在给定的 urlpatterns 列表中添加所需的 URL。默认情况下，我们有一整套 URL 用于 Django 的内置管理后端系统。我们会完全删除它。我们还得到一些非常有用的文档字符串，它告诉我们如何向 Django 项目添加路由。我们需要调用 path()，伴随三个参数：所需的路由，作为字符串（没有前导斜线）处理该路由的视图函数（只能有一个函数！）在 Django 项目中路由的名称让我们导入 HelloWorld 视图并将其附加到主路径 / 。我们可以从 urlpatterns 中删除 admin 的路径，因为我们不会使用它。# django_todo/urls.py, after the big doc string from django.urls import path from django_todo.views import HelloWorld urlpatterns = [ path('', HelloWorld.as_view(), name="hello"), ]好吧，这里有一点不同。我们指定的路由只是一个空白字符串，为什么它会工作？Django 假设我们声明的每个路由都以一个前导斜杠开头，我们只是在初始域名后指定资源路由。如果一条路由没有去往一个特定的资源，而只是一个主页，那么该路由是 ''，实际上是“没有资源”。HelloWorld 视图是从我们刚刚创建的 views.py 文件导入的。为了执行此导入，我们需要更新 settings.py 中的 INSTALLED_APPS 列表使其包含 django_todo。是的，这有点奇怪。以下是一种理解方式。INSTALLED_APPS 指的是 Django 认为可导入的目录或包的列表。它是 Django 处理项目的各个组件的方式，比如安装了一个包，而不需要经过 setup.py 的方式。我们希望将 django_todo 目录视为可导入的包，因此我们将该目录包含在 INSTALLED_APPS 中。现在，在该目录中的任何模块也是可导入的。所以我们得到了我们的视图。path 函数只将视图函数作为第二个参数，而不仅仅是基于类的视图。幸运的是，所有有效的基于 Django 类的视图都包含 .as_view() 方法。它的工作是将基于类的视图的所有优点汇总到一个视图函数中并返回该视图函数。所以，我们永远不必担心转换的工作。相反，我们只需要考虑业务逻辑，让 Django 和 Django REST 框架处理剩下的事情。让我们在浏览器中打开它！Django 提供了自己的本地开发服务器，可通过 manage.py 访问。让我们切换到包含 manage.py 的目录并输入：(django-someHash) $ ./manage.py runserver Performing system checks... System check identified no issues (0 silenced). August 01, 2018 - 16:47:24 Django version 2.0.7, using settings 'django_todo.settings' Starting development server at http://127.0.0.1:8000/ Quit the server with CONTROL-C.当 runserver 执行时，Django 会检查以确保项目（或多或少）正确连接在一起。这不是万无一失的，但确实会发现一些明显的问题。如果我们的数据库与代码不同步，它会通知我们。毫无疑问，因为我们没有将任何应用程序的东西提交到我们的数据库，但现在这样做还是可以的。让我们访问 http://127.0.0.1:8000 来查看 HelloWorld 视图的输出。咦？这不是我们在 Pyramid、Flask 和 Tornado 中看到的明文数据。当使用 Django REST 框架时，HTTP 响应（在浏览器中查看时）是这样呈现的 HTML，以红色显示我们的实际 JSON 响应。但不要担心！如果我们在命令行中使用 curl 快速访问 http://127.0.0.1:8000，我们就不会得到任何花哨的 HTML，只有内容。# 注意：在不同的终端口窗口中执行此操作，在虚拟环境之外 $ curl http://127.0.0.1:8000 "Hello, world!"棒极了！Django REST 框架希望我们在使用浏览器浏览时拥有一个人性化的界面。这是有道理的，如果在浏览器中查看 JSON，通常是因为人们想要检查它是否正确，或者在设计一些消费者 API 时想要了解 JSON 响应。这很像你从 Postman 中获得的东西。无论哪种方式，我们都知道我们的视图工作了！酷！让我们概括一下我们做过的事情：使用 django-admin startproject <项目名称> 开始一个项目使用环境变量来更新 django_todo/settings.py 中的 DEBUG、SECRET_KEY，还有 DATABASES 字典安装 Django REST 框架，并将它添加到 INSTALLED_APPS创建 django_todo/views.py 来包含我们的第一个类视图，它返回响应 “Hello, world!”更新 django_todo/urls.py，其中包含我们的根路由在 django_todo/settings.py 中更新 INSTALLED_APPS 以包含 django_todo 包创建模型现在让我们来创建数据模型吧。Django 项目的整个基础架构都是围绕数据模型构建的，它是这样编写的，每个数据模型够可以拥有自己的小天地，拥有自己的视图，自己与其资源相关的 URL 集合，甚至是自己的测试（如果我们想要的话）。如果我们想构建一个简单的 Django 项目，我们可以通过在 django_todo 目录中编写我们自己的 models.py 文件并将其导入我们的视图来避免这种情况。但是，我们想以“正确”的方式编写 Django 项目，因此我们应该尽可能地将模型拆分成符合 Django Way™（Django 风格）的包。Django Way 涉及创建所谓的 Django “应用程序”，它本身并不是单独的应用程序，它们没有自己的设置和诸如此类的东西（虽然它们也可以）。但是，它们可以拥有一个人们可能认为属于独立应用程序的东西：一组自建的 URL一组自建的 HTML 模板（如果我们想要提供 HTML）一个或多个数据模型一套自建的视图一套自建的测试它们是独立的，因此可以像独立应用程序一样轻松共享。实际上，Django REST 框架是 Django 应用程序的一个例子。它包含自己的视图和 HTML 模板，用于提供我们的 JSON。我们只是利用这个 Django 应用程序将我们的项目变成一个全面的 RESTful API 而不用那么麻烦。要为我们的待办事项列表项创建 Django 应用程序，我们将要使用 manage.py 的 startapp 命令。(django-someHash) $ ./manage.py startapp todostartapp 命令成功执行后没有输出。我们可以通过使用 ls 来检查它是否完成它应该做的事情。(django-someHash) $ ls Pipfile Pipfile.lock django_todo manage.py todo看看：我们有一个全新的 todo 目录。让我们看看里面!(django-someHash) $ ls todo __init__.py admin.py apps.py migrations models.py tests.py views.py以下是 manage.py startapp 创建的文件：__init__.py 是空文件。它之所以存在是因为此目录可看作是模型、视图等的有效导入路径。admin.py 不是空文件。它用于在 Django admin 中规范化这个应用程序的模型，我们在本文中没有涉及到它。apps.py 这里基本不起作用。它有助于规范化 Django admin 的模型。migrations 是一个包含我们数据模型快照的目录。它用于更新数据库。这是少数几个内置了数据库管理的框架之一，其中一部分允许我们更新数据库，而不必拆除它并重建它以更改 Schema。models.py 是数据模型所在。tests.py 是测试所在的地方，如果我们需要写测试。views.py 用于我们编写的与此应用程序中的模型相关的视图。它们不是一定得写在这里。例如，我们可以在 django_todo/views.py 中写下我们所有的视图。但是，它在这个应用程序中更容易将我们的概念理清。在覆盖了许多概念的扩展应用程序的关系之间会变得更加密切。它并没有为这个应用程序创建 urls.py 文件，但我们可以自己创建。(django-someHash) $ touch todo/urls.py在继续之前，我们应该帮自己一个忙，将这个新 Django 应用程序添加到 django_todo/settings.py 中的 INSTALLED_APPS 列表中。# settings.py INSTALLED_APPS = [ 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'rest_framework', 'django_todo', 'todo' # <--- 添加了这行 ]检查 todo/models.py 发现 manage.py 已经为我们编写了一些代码。不同于在 Flask、Tornado 和 Pyramid 实现中创建模型的方式，Django 不利用第三方来管理数据库会话或构建其对象实例。它全部归入 Django 的 django.db.models 子模块。然而，建立模型的方式或多或少是相同的。要在 Django 中创建模型，我们需要构建一个继承自 models.Model 的 class，将应用于该模型实例的所有字段都应视为类属性。我们不像过去那样从 SQLAlchemy 导入列和字段类型，而是直接从 django.db.models 导入。# todo/models.py from django.db import models class Task(models.Model): """Tasks for the To Do list.""" name = models.CharField(max_length=256) note = models.TextField(blank=True, null=True) creation_date = models.DateTimeField(auto_now_add=True) due_date = models.DateTimeField(blank=True, null=True) completed = models.BooleanField(default=False)虽然 Django 的需求和基于 SQLAlchemy 的系统之间存在一些明显的差异，但总体内容和结构或多或少相同。让我们来指出这些差异。我们不再需要为对象实例声明自动递增 ID 的单独字段。除非我们指定一个不同的字段作为主键，否则 Django 会为我们构建一个。我们只是直接引用数据类型作为列本身，而不是实例化传递数据类型对象的 Column 对象。Unicode 字段变为 models.CharField 或 models.TextField。CharField 用于特定最大长度的小文本字段，而 TextField 用于任何数量的文本。TextField 应该是空白的，我们以两种方式指定它。blank = True 表示当构建此模型的实例，并且正在验证附加到该字段的数据时，该数据是可以为空的。这与 null = True 不同，后者表示当构造此模型类的表时，对应于 note 的列将允许空白或为 NULL。因此，总而言之，blank = True 控制如何将数据添加到模型实例，而 null = True 控制如何构建保存该数据的数据库表。DateTime 字段增加了一些属性，并且能够为我们做一些工作，使得我们不必修改类的 __init__ 方法。对于 creation_date 字段，我们指定 auto_now_add = True。在实际意义上意味着，当创建一个新模型实例时，Django 将自动记录现在的日期和时间作为该字段的值。这非常方便！当 auto_now_add 及其类似属性 auto_now 都没被设置为 True 时，DateTimeField 会像其它字段一样需要预期的数据。它需要提供一个适当的 datetime 对象才能生效。due_date 列的 blank 和 null 属性都设置为 True，这样待办事项列表中的项目就可以成为将来某个时间点完成，没有确定的日期或时间。BooleanField 最终可以取两个值：True 或 False。这里，默认值设置为 False。管理数据库如前所述，Django 有自己的数据库管理方式。我们可以利用 Django 提供的 manage.py 脚本，而不必编写任何关于数据库的代码。它不仅可以管理我们数据库的表的构建，还可以管理我们希望对这些表进行的任何更新，而不必将整个事情搞砸！因为我们构建了一个新模型，所以我们需要让数据库知道它。首先，我们需要将与此模型对应的模式放入代码中。manage.py 的 makemigrations 命令对我们构建的模型类及其所有字段进行快照。它将获取该信息并将其打包成一个 Python 脚本，该脚本将存在于特定 Django 应用程序的 migrations 目录中。永远没有理由直接运行这个迁移脚本。它的存在只是为了让 Django 可以使用它作为更新数据库表的基础，或者在我们更新模型类时继承信息。(django-someHash) $ ./manage.py makemigrations Migrations for 'todo': todo/migrations/0001_initial.py - Create model Task这将查找 INSTALLED_APPS 中列出的每个应用程序，并检查这些应用程序中存在的模型。然后，它将检查相应的 migrations 目录中的迁移文件，并将它们与每个 INSTALLED_APPS 中的模型进行比较。如果模型已经升级超出最新迁移所应存在的范围，则将创建一个继承自最新迁移文件的新迁移文件，它将自动命名，并且还会显示一条消息，说明自上次迁移以来发生了哪些更改。如果你上次处理 Django 项目已经有一段时间了，并且不记得模型是否与迁移同步，那么你无需担心。makemigrations 是一个幂等操作。无论你运行 makemigrations 一次还是 20 次，migrations 目录只有一个与当前模型配置的副本。更棒的是，当我们运行 ./manage.py runserver 时，Django 检测到我们的模型与迁移不同步，它会用彩色文本告诉我们以便我们可以做出适当的选择。下一个要点是至少让每个人访问一次：创建一个迁移文件不会立即影响我们的数据库。当我们运行 makemigrations 时，我们布置我们的 Django 项目定义了给定的表应该如何创建和最终查找。我们仍要将这些更改应用于数据库。这就是 migrate 命令的用途。(django-someHash) $ ./manage.py migrate Operations to perform: Apply all migrations: admin, auth, contenttypes, sessions, todo 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 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 sessions.0001_initial... OK Applying todo.0001_initial... OK当我们应用这些迁移时，Django 首先检查其他 INSTALLED_APPS 是否有需要应用的迁移，它大致按照列出的顺序检查它们。我们希望我们的应用程序最后列出，因为我们希望确保，如果我们的模型依赖于任何 Django 的内置模型，我们所做的数据库更新不会受到依赖性问题的影响。我们还有另一个要构建的模型：User 模型。但是，因为我们正在使用 Django，事情有一些变化。许多应用程序需要某种类型的用户模型，Django 的 django.contrib.auth 包构建了自己的用户模型供我们使用。如果无需用户所需要的身份验证令牌，我们可以继续使用它而不是重新发明轮子。但是，我们需要那个令牌。我们可以通过两种方式来处理这个问题。继承 Django 的 User 对象，我们自己的对象通过添加 token 字段来扩展它创建一个与 Django 的 User 对象一对一关系的新对象，其唯一目的是持有一个令牌我习惯于建立对象关系，所以让我们选择第二种选择。我们称之为 Owner，因为它基本上具有与 User 类似的内涵，这就是我们想要的。出于纯粹的懒惰，我们可以在 todo/models.py 中包含这个新的 Owner 对象，但是不要这样做。Owner 没有明确地与任务列表上的项目的创建或维护有关。从概念上讲，Owner 只是任务的所有者。甚至有时候我们想要扩展这个 Owner 以包含与任务完全无关的其他数据。为了安全起见，让我们创建一个 owner 应用程序，其工作是容纳和处理这个 Owner 对象。(django-someHash) $ ./manage.py startapp owner不要忘记在 settings.py 文件中的 INSTALLED_APPS 中添加它。 `INSTALLED_APPS = [ 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'rest_framework', 'django_todo', 'todo', 'owner']`如果我们查看 Django 项目的根目录，我们现在有两个 Django 应用程序：(django-someHash) $ ls Pipfile Pipfile.lock django_todo manage.py owner todo在 owner/models.py 中，让我们构建这个 Owner 模型。如前所述，它与 Django 的内置 User 对象有一对一的关系。我们可以用 Django 的 models.OneToOneField 强制实现这种关系。# owner/models.py from django.db import models from django.contrib.auth.models import User import secrets class Owner(models.Model): """The object that owns tasks.""" user = models.OneToOneField(User, on_delete=models.CASCADE) token = models.CharField(max_length=256) def __init__(self, *args, **kwargs): """On construction, set token.""" self.token = secrets.token_urlsafe(64) super().__init__(*args, **kwargs)这表示 Owner 对象对应到 User 对象，每个 user 实例有一个 owner 实例。on_delete = models.CASCADE 表示如果相应的 User 被删除，它所对应的 Owner 实例也将被删除。让我们运行 makemigrations 和 migrate 来将这个新模型放入到我们的数据库中。(django-someHash) $ ./manage.py makemigrations Migrations for 'owner': owner/migrations/0001_initial.py - Create model Owner (django-someHash) $ ./manage.py migrate Operations to perform: Apply all migrations: admin, auth, contenttypes, owner, sessions, todo Running migrations: Applying owner.0001_initial... OK现在我们的 Owner 需要拥有一些 Task 对象。它与上面看到的 OneToOneField 非常相似，只不过我们会在 Task 对象上贴一个 ForeignKey 字段指向 Owner。# todo/models.py from django.db import models from owner.models import Owner class Task(models.Model): """Tasks for the To Do list.""" name = models.CharField(max_length=256) note = models.TextField(blank=True, null=True) creation_date = models.DateTimeField(auto_now_add=True) due_date = models.DateTimeField(blank=True, null=True) completed = models.BooleanField(default=False) owner = models.ForeignKey(Owner, on_delete=models.CASCADE)每个待办事项列表任务只有一个可以拥有多个任务的所有者。删除该所有者后，他们拥有的任务都会随之删除。现在让我们运行 makemigrations 来获取我们的数据模型设置的新快照，然后运行 migrate 将这些更改应用到我们的数据库。(django-someHash) django $ ./manage.py makemigrations You are trying to add a non-nullable field 'owner' to task without a default; we can't do that (the database needs something to populate existing rows). Please select a fix: 1) Provide a one-off default now (will be set on all existing rows with a null value for this column) 2) Quit, and let me add a default in models.py不好了！出现了问题！发生了什么？其实，当我们创建 Owner 对象并将其作为 ForeignKey 添加到 Task 时，要求每个 Task 都需要一个 Owner。但是，我们为 Task 对象进行的第一次迁移不包括该要求。因此，即使我们的数据库表中没有数据，Django 也会对我们的迁移进行预先检查，以确保它们兼容，而我们提议的这种新迁移不是。有几种方法可以解决这类问题：退出当前迁移并构建一个包含当前模型配置的新迁移将一个默认值添加到 Task 对象的 owner 字段允许任务为 owner 字段设置 NULL 值方案 2 在这里没有多大意义。我们建议，默认情况下，任何创建的 Task 都会对应到某个默认所有者，尽管默认所有者不一定存在。 方案 1 要求我们销毁和重建我们的迁移，而我们应该把它们留下。让我们考虑选项 3。在这种情况下，如果我们允许 Task 表为所有者提供空值，它不会很糟糕。从这一点开始创建的任何任务都必然拥有一个所有者。如果你的数据库表并非不能接受重新架构，请删除该迁移、删除表并重建迁移。# todo/models.py from django.db import models from owner.models import Owner class Task(models.Model): """Tasks for the To Do list.""" name = models.CharField(max_length=256) note = models.TextField(blank=True, null=True) creation_date = models.DateTimeField(auto_now_add=True) due_date = models.DateTimeField(blank=True, null=True) completed = models.BooleanField(default=False) owner = models.ForeignKey(Owner, on_delete=models.CASCADE, null=True) (django-someHash) $ ./manage.py makemigrations Migrations for 'todo': todo/migrations/0002_task_owner.py - Add field owner to task (django-someHash) $ ./manage.py migrate Operations to perform: Apply all migrations: admin, auth, contenttypes, owner, sessions, todo Running migrations: Applying todo.0002_task_owner... OK酷！我们有模型了！欢迎使用 Django 声明对象的方式。出于更好的权衡，让我们确保无论何时制作 User，它都会自动与新的 Owner 对象对应。我们可以使用 Django 的 signals 系统来做到这一点。基本上，我们确切地表达了意图：“当我们得到一个新的 User 被构造的信号时，构造一个新的 Owner 并将新的 User 设置为 Owner 的 user 字段。”在实践中看起来像这样：# owner/models.py from django.contrib.auth.models import User from django.db import models from django.db.models.signals import post_save from django.dispatch import receiver import secrets class Owner(models.Model): """The object that owns tasks.""" user = models.OneToOneField(User, on_delete=models.CASCADE) token = models.CharField(max_length=256) def __init__(self, *args, **kwargs): """On construction, set token.""" self.token = secrets.token_urlsafe(64) super().__init__(*args, **kwargs) @receiver(post_save, sender=User) def link_user_to_owner(sender, **kwargs): """If a new User is saved, create a corresponding Owner.""" if kwargs['created']: owner = Owner(user=kwargs['instance']) owner.save()我们设置了一个函数，用于监听从 Django 中内置的 User 对象发送的信号。它正在等待 User 对象被保存之后的情况。这可以来自新的 User 或对现有 User 的更新。我们在监听功能中辨别出两种情况。如果发送信号的东西是新创建的实例，kwargs ['created'] 将具有值 True。如果是 True 的话，我们想做点事情。如果它是一个新实例，我们创建一个新的 Owner，将其 user 字段设置为创建的新 User 实例。之后，我们 save() 新的 Owner。如果一切正常，这将提交更改到数据库。如果数据没通过我们声明的字段的验证，它将失败。现在让我们谈谈我们将如何访问数据。访问模型数据在 Flask、Pyramid 和 Tornado 框架中，我们通过对某些数据库会话运行查询来访问模型数据。也许它被附加到 request 对象，也许它是一个独立的 session 对象。无论如何，我们必须建立与数据库的实时连接并在该连接上进行查询。这不是 Django 的工作方式。默认情况下，Django 不利用任何第三方对象关系映射（ORM）与数据库进行通信。相反，Django 允许模型类维护自己与数据库的对话。从 django.db.models.Model 继承的每个模型类都会附加一个 objects 对象。这将取代我们熟悉的 session 或 dbsession。让我们打开 Django 给我们的特殊 shell，并研究这个 objects 对象是如何工作的。(django-someHash) $ ./manage.py shell Python 3.7.0 (default, Jun 29 2018, 20:13:13) [Clang 9.1.0 (clang-902.0.39.2)] on darwin Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>>Django shell 与普通的 Python shell 不同，因为它知道我们正在构建的 Django 项目，可以轻松导入我们的模型、视图、设置等，而不必担心安装包。我们可以通过简单的 import 访问我们的模型。>>> from owner.models import Owner >>> Owner <class 'owner.models.Owner'>目前，我们没有 Owner 实例。我们可以通过 Owner.objects.all() 查询它们。>>> Owner.objects.all() <QuerySet []>无论何时我们在 <Model> .objects 对象上运行查询方法，我们都会得到 QuerySet。为了我们的目的，它实际上是一个列表，这个列表向我们显示它是空的。让我们通过创建一个 User 来创建一个 Owner。>>> from django.contrib.auth.models import User >>> new_user = User(username='kenyattamurphy', email='kenyatta.murphy@gmail.com') >>> new_user.set_password('wakandaforever') >>> new_user.save()如果我们现在查询所有的 Owner，我们应该会找到 Kenyatta。>>> Owner.objects.all() <QuerySet [<Owner: Owner object (1)>]>棒极了！我们得到了数据！序列化模型我们将在 “Hello World” 之外来回传递数据。因此，我们希望看到某种类似于 JSON 类型的输出，它可以很好地表示数据。获取该对象的数据并将其转换为 JSON 对象以通过 HTTP 提交是数据序列化的一种方式。在序列化数据时，我们正在获取我们目前拥有的数据并重新格式化以适应一些标准的、更易于理解的形式。如果我用 Flask、Pyramid 和 Tornado 这样做，我会在每个模型上创建一个新方法，让用户可以直接调用 to_json()。to_json() 的唯一工作是返回一个 JSON 可序列化的（即数字、字符串、列表、字典）字典，其中包含我想要为所讨论的对象显示的任何字段。对于 Task 对象，它可能看起来像这样：class Task(Base): ...all the fields... def to_json(self): """Convert task attributes to a JSON-serializable dict.""" return { 'id': self.id, 'name': self.name, 'note': self.note, 'creation_date': self.creation_date.strftime('%m/%d/%Y %H:%M:%S'), 'due_date': self.due_date.strftime('%m/%d/%Y %H:%M:%S'), 'completed': self.completed, 'user': self.user_id }这不花哨，但它确实起到了作用。然而，Django REST 框架为我们提供了一个对象，它不仅可以为我们这样做，还可以在我们想要创建新对象实例或更新现有实例时验证输入，它被称为 ModelSerializer。Django REST 框架的 ModelSerializer 是我们模型的有效文档。如果没有附加模型，它们就没有自己的生命（因为那里有 Serializer 类）。它们的主要工作是准确地表示我们的模型，并在我们的模型数据需要序列化并通过线路发送时，将其转换为 JSON。Django REST 框架的 ModelSerializer 最适合简单对象。举个例子，假设我们在 Task 对象上没有 ForeignKey。我们可以为 Task 创建一个序列化器，它将根据需要将其字段值转换为 JSON，声明如下：# todo/serializers.py from rest_framework import serializers from todo.models import Task class TaskSerializer(serializers.ModelSerializer): """Serializer for the Task model.""" class Meta: model = Task fields = ('id', 'name', 'note', 'creation_date', 'due_date', 'completed')在我们新的 TaskSerializer 中，我们创建了一个 Meta 类。Meta 的工作就是保存关于我们试图序列化的东西的信息（或元数据）。然后，我们会注意到要显示的特定字段。如果我们想要显示所有字段，我们可以简化过程并使用 __all __。或者，我们可以使用 exclude 关键字而不是 fields 来告诉 Django REST 框架我们想要除了少数几个字段以外的每个字段。我们可以拥有尽可能多的序列化器，所以也许我们想要一个用于一小部分字段，而另一个用于所有字段？在这里都可以。在我们的例子中，每个 Task 和它的所有者 Owner 之间都有一个关系，必须在这里反映出来。因此，我们需要借用 serializers.PrimaryKeyRelatedField 对象来指定每个 Task 都有一个 Owner，并且该关系是一对一的。它的所有者将从已有的全部所有者的集合中找到。我们通过对这些所有者进行查询并返回我们想要与此序列化程序关联的结果来获得该集合：Owner.objects.all()。我们还需要在字段列表中包含 owner，因为我们总是需要一个与 Task 相关联的 Owner。# todo/serializers.py from rest_framework import serializers from todo.models import Task from owner.models import Owner class TaskSerializer(serializers.ModelSerializer): """Serializer for the Task model.""" owner = serializers.PrimaryKeyRelatedField(queryset=Owner.objects.all()) class Meta: model = Task fields = ('id', 'name', 'note', 'creation_date', 'due_date', 'completed', 'owner')现在构建了这个序列化器，我们可以将它用于我们想要为我们的对象做的所有 CRUD 操作：如果我们想要 GET 一个特定的 Task 的 JSON 类型版本，我们可以做 TaskSerializer((some_task).data如果我们想接受带有适当数据的 POST 来创建一个新的 Task，我们可以使用 TaskSerializer(data = new_data).save()如果我们想用 PUT 更新一些现有数据，我们可以用 TaskSerializer(existing_task, data = data).save()我们没有包括 delete，因为我们不需要对 delete 操作做任何事情。如果你可以删除一个对象，只需使用 object_instance.delete()。以下是一些序列化数据的示例：>>> from todo.models import Task >>> from todo.serializers import TaskSerializer >>> from owner.models import Owner >>> from django.contrib.auth.models import User >>> new_user = User(username='kenyatta', email='kenyatta@gmail.com') >>> new_user.save_password('wakandaforever') >>> new_user.save() # creating the User that builds the Owner >>> kenyatta = Owner.objects.first() # 找到 kenyatta 的所有者 >>> new_task = Task(name="Buy roast beef for the Sunday potluck", owner=kenyatta) >>> new_task.save() >>> TaskSerializer(new_task).data {'id': 1, 'name': 'Go to the supermarket', 'note': None, 'creation_date': '2018-07-31T06:00:25.165013Z', 'due_date': None, 'completed': False, 'owner': 1}使用 ModelSerializer 对象可以做更多的事情，我建议查看文档以获得更强大的功能。否则，这就是我们所需要的。现在是时候深入视图了。查看视图我们已经构建了模型和序列化器，现在我们需要为我们的应用程序设置视图和 URL。毕竟，对于没有视图的应用程序，我们无法做任何事情。我们已经看到了上面的 HelloWorld 视图的示例。然而，这总是一个人为的、概念验证的例子，并没有真正展示 Django REST 框架的视图可以做些什么。让我们清除 HelloWorld 视图和 URL，这样我们就可以从我们的视图重新开始。我们要构建的第一个视图是 InfoView。与之前的框架一样，我们只想打包并发送一个我们用到的路由的字典。视图本身可以存在于 django_todo.views 中，因为它与特定模型无关（因此在概念上不属于特定应用程序）。# django_todo/views.py from rest_framework.response import JsonResponse from rest_framework.views import APIView class InfoView(APIView): """List of routes for this API.""" def get(self, request): output = { 'info': 'GET /api/v1', 'register': 'POST /api/v1/accounts', 'single profile detail': 'GET /api/v1/accounts/<username>', 'edit profile': 'PUT /api/v1/accounts/<username>', 'delete profile': 'DELETE /api/v1/accounts/<username>', 'login': 'POST /api/v1/accounts/login', 'logout': 'GET /api/v1/accounts/logout', "user's tasks": 'GET /api/v1/accounts/<username>/tasks', "create task": 'POST /api/v1/accounts/<username>/tasks', "task detail": 'GET /api/v1/accounts/<username>/tasks/<id>', "task update": 'PUT /api/v1/accounts/<username>/tasks/<id>', "delete task": 'DELETE /api/v1/accounts/<username>/tasks/<id>' } return JsonResponse(output)这与我们在 Tornado 中所拥有的完全相同。让我们将它放置到合适的路由并继续。为了更好的测试，我们还将删除 admin/ 路由，因为我们不会在这里使用 Django 管理后端。# in django_todo/urls.py from django_todo.views import InfoView from django.urls import path urlpatterns = [ path('api/v1', InfoView.as_view(), name="info"), ]连接模型与视图让我们弄清楚下一个 URL，它将是创建新的 Task 或列出用户现有任务的入口。这应该存在于 todo 应用程序的 urls.py 中，因为它必须专门处理 Task对象而不是整个项目的一部分。# in todo/urls.py from django.urls import path from todo.views import TaskListView urlpatterns = [ path('', TaskListView.as_view(), name="list_tasks") ]这个路由处理的是什么？我们根本没有指定特定用户或路径。由于会有一些路由需要基本路径 /api/v1/accounts/<username>/tasks，为什么我们只需写一次就能一次又一次地写它？Django 允许我们用一整套 URL 并将它们导入 django_todo/urls.py 文件。然后，我们可以为这些导入的 URL 中的每一个提供相同的基本路径，只关心可变部分，你知道它们是不同的。# in django_todo/urls.py from django.urls import include, path from django_todo.views import InfoView urlpatterns = [ path('api/v1', InfoView.as_view(), name="info"), path('api/v1/accounts/<str:username>/tasks', include('todo.urls')) ]现在，来自 todo/urls.py 的每个 URL 都将以路径 api/v1/accounts/<str:username>/tasks 为前缀。让我们在 todo/views.py 中构建视图。# todo/views.py from django.shortcuts import get_object_or_404 from rest_framework.response import JsonResponse from rest_framework.views import APIView from owner.models import Owner from todo.models import Task from todo.serializers import TaskSerializer class TaskListView(APIView): def get(self, request, username, format=None): """Get all of the tasks for a given user.""" owner = get_object_or_404(Owner, user__username=username) tasks = Task.objects.filter(owner=owner).all() serialized = TaskSerializer(tasks, many=True) return JsonResponse({ 'username': username, 'tasks': serialized.data })这里一点代码里面有许多要说明的，让我们来看看吧。我们从与我们一直使用的 APIView 的继承开始，为我们的视图奠定基础。我们覆盖了之前覆盖的相同 get 方法，添加了一个参数，允许我们的视图从传入的请求中接收 username。然后我们的 get 方法将使用 username 来获取与该用户关联的 Owner。这个 get_object_or_404 函数允许我们这样做，添加一些特殊的东西以方便使用。如果无法找到指定的用户，那么查找任务是没有意义的。实际上，我们想要返回 404 错误。get_object_or_404 根据我们传入的任何条件获取单个对象，并返回该对象或引发 Http 404 异常。我们可以根据对象的属性设置该条件。Owner 对象都通过 user 属性附加到 User。但是，我们没有要搜索的 User 对象，我们只有一个 username。所以，当你寻找一个 Owner 时，我们对 get_object_or_404 说：通过指定 user__username（这是两个下划线）来检查附加到它的 User 是否具有我想要的 username。通过 QuerySet 过滤时，这两个下划线表示 “此嵌套对象的属性”。这些属性可以根据需要进行深度嵌套。我们现在拥有与给定用户名相对应的 Owner。我们使用 Owner 来过滤所有任务，只用 Task.objects.filter 检索它拥有的任务。我们可以使用与 get_object_or_404 相同的嵌套属性模式来钻入连接到 Tasks 的 Owner 的 User（tasks = Task.objects.filter(owner__user__username = username)).all()），但是没有必要那么宽松。Task.objects.filter(owner = owner).all() 将为我们提供与我们的查询匹配的所有 Task 对象的QuerySet。很棒。然后，TaskSerializer 将获取 QuerySet 及其所有数据以及 many = True 标志，以通知其为项目集合而不是仅仅一个项目，并返回一系列序列化结果。实际上是一个词典列表。最后，我们使用 JSON 序列化数据和用于查询的用户名提供传出响应。处理 POST 请求post 方法看起来与我们之前看到的有些不同。# still in todo/views.py # ...other imports... from rest_framework.parsers import JSONParser from datetime import datetime class TaskListView(APIView): def get(self, request, username, format=None): ... def post(self, request, username, format=None): """Create a new Task.""" owner = get_object_or_404(Owner, user__username=username) data = JSONParser().parse(request) data['owner'] = owner.id if data['due_date']: data['due_date'] = datetime.strptime(data['due_date'], '%d/%m/%Y %H:%M:%S') new_task = TaskSerializer(data=data) if new_task.is_valid(): new_task.save() return JsonResponse({'msg': 'posted'}, status=201) return JsonResponse(new_task.errors, status=400)当我们从客户端接收数据时，我们使用 JSONParser().parse(request) 将其解析为字典。我们将所有者添加到数据中并格式化任务的 due_date（如果存在）。我们的 TaskSerializer 完成了繁重的任务。它首先接收传入的数据并将其转换为我们在模型上指定的字段。然后验证该数据以确保它适合指定的字段。如果附加到新 Task 的数据有效，它将使用该数据构造一个新的 Task 对象并将其提交给数据库。然后我们发回适当的“耶！我们做了一件新东西！”响应。如果没有，我们收集 TaskSerializer 生成的错误，并将这些错误发送回客户端，并返回 400 Bad Request 状态代码。如果我们要构建 put 视图来更新 Task，它看起来会非常相似。主要区别在于，当我们实例化 TaskSerializer 时，我们将传递旧对象和该对象的新数据，如 TaskSerializer(existing_task，data = data)。我们仍然会进行有效性检查并发回我们想要发回的响应。总结Django 作为一个框架是高度可定制的，每个人都有自己打造 Django 项目的方式。我在这里写出来的方式不一定是 Django 建立项目的确切方式。它只是 a) 我熟悉的方式，以及 b) 利用 Django 的管理系统。当你将概念切分到不同的小块时，Django 项目的复杂性会增加。这样做是为了让多个人更容易为整个项目做出贡献，而不会麻烦彼此。然而，作为 Django 项目的大量文件映射并不能使其更高效或自然地偏向于微服务架构。相反，它很容易成为一个令人困惑的独石应用，这可能对你的项目仍然有用，它也可能使你的项目难以管理，尤其是随着项目的增长。仔细考虑你的需求并使用合适的工具来完成正确的工作。对于像这样的简单项目，Django 可能不是合适的工具。Django 旨在处理多种模型，这些模型涵盖了不同的项目领域，但它们可能有一些共同点。这个项目是一个小型的双模型项目，有一些路由。即便我们把它构建更复杂，也只有七条路由，而仍然只是相同的两个模型。这还不足以证明一个完整的 Django 项目。如果我们期望这个项目能够拓展，那么将会是一个很好的选择。这不是那种项目。这就是使用火焰喷射器来点燃蜡烛，绝对是大材小用了。尽管如此，Web 框架就是一个 Web 框架，无论你使用哪个框架。它都可以接收请求并做出任何响应，因此你可以按照自己的意愿进行操作。只需要注意你选择的框架所带来的开销。就是这样！我们已经到了这个系列的最后！我希望这是一次启发性的冒险。当你在考虑如何构建你的下一个项目时，它将帮助你做出的不仅仅是最熟悉的选择。请务必阅读每个框架的文档，以扩展本系列中涉及的任何内容（因为它没有那么全面）。每个人都有一个广阔的世界。愉快地写代码吧！via: https://opensource.com/article/18/8/django-framework作者：Nicholas Hunt-Walker 选题：lujun9972 译者：MjSeven 校对：Bestony, wxy本文由 LCTT 原创编译，Linux中国 荣誉推出