Flask Web Development —— 大型应用程序结构.doc

Flask Web Development —— 大型应用程序结构 虽然小型web应用程序用单个脚本可以很方便，但这种方法却不能很好地扩展。随着应用变得复杂，在单个大的源文件中处理会变得问题重重。 与大多数其他web框架不同，Flask对大型项目没有特定的组织方式；应用程序的结构完全交给开发人员自己决定。在这一章，提出一个可能的方式来组织管理一个大型应用程序的包和模块。这种结构将用于书中其余的示例中。 示例7-1展示基本Flask应用程序结构 示例7-1：基本多文件Flask应用结构 这个结构有四个顶层目录： Flask应用一般放置在名为app的目录下。 migrations目录包含数据库迁移脚本，这和之前说的一样。 单元测试放置在test目录下 venv目录包含Python虚拟环境，这和之前说的也是一样的。 还有一些新的文件： requirements.txt列出一些依赖包，这样就可以很容易的在不同的计算机上部署一个相同的虚拟环境。 config.py存储了一些配置设置。 manage.py用于启动应用程序和其他应用程序任务。 为了帮助你完全理解这个结构，下面会描述将hello.py应用改为符合这一结构的整个流程。 应用程序通常需要几个配置设置。最好的例子就是在开发过程中需要使用不同的数据库，测试，生产环境，这样他们可以做到互不干扰。 我们可以使用配置类的层次结构来代替hello.py中的简单类字典结构配置。示例7-2展示了config.py文件。 示例7-2. config.py：应用程序配置 Config基类包含一些相同配置；不同的子类定义不同的配置。额外配置可以在需要的时候在加入。 为了让配置更灵活更安全，一些设置可以从环境变量中导入。例如，SECRET_KEY，由于它的敏感性，可以在环境中设置，但如果环境中没有定义就必须提供一个默认值。 在三个配置中SQLALCHEMY_DATABASE_URI变量可以分配不同的值。这样应用程序可以在不同的配置下运行，每个可以使用不同的数据库。 配置类可以定义一个将应用程序实例作为参数的init_app()静态方法。这里特定于配置的初始化是可以执行的。这里Config基类实现一个空init_app()方法。 在配置脚本的底部，这些不同的配置是注册在配置字典中。将其中一个配置(开发配置)注册为默认配置。 应用程序包放置了所有应用程序代码、模板和静态文件。它被简单的称为app，也可以给定一个特定于应用的名称(如果需要的话)。templates和static目录是应用的一部分，因此这两个目录应该放置在app中。数据库模型和电子邮件支持功能也要置入到这个包中，每个都以app/models.py和app/email.py形式存入自己的模块当中。 在单个文件中创建应用程序的方式非常方便，但是它有一个大缺点。因为应用程序创建在全局范围，没有办法动态的适应应用配置的更改:脚本运行时，应用程序实例已经创建，所以它已经来不及更改配置。对于单元测试这是特别重要的，因为有时需要在不同的配置下运行应用程序来获得更好的测试覆盖率。 解决这一问题的方法就是将应用程序放入一个工厂函数中来延迟创建，这样就可以从脚本中显式的调用。 这不仅给脚本充足的时间来设置配置，也能用于创建多个应用程序实例——一些在测试过程中非常有用的东西。被定义在app包的构造函数中的应用程序工厂函数会在示例7-3中展示。 这个构造函数导入大部分当前需要使用的扩展，但因为没有应用程序实例初始化它们，它可以被创建但不初始化通过不传递参数给它们的构造函数。create_app()即应用程序工厂函数，需要传入用于应用程序的配置名。配置中的设置被保存在config.py中的一个类中，可以使用Flask的app.config配置对象的from_object()方法来直接导入。配置对象可以通过对象名从config字典中选出。一旦应用程序被创建且配置好，扩展就可以被初始化。调用扩展里的init_app()之前先创建并完成初始化工作。 示例7-3. app/?init__.py：应用程序包构造函数 工厂函数返回创建的应用程序实例，但是请注意，在当前状态下使用工厂函数创建的应用程序是不完整的，因为它们没有路由和自定义错误页面处理程序。这是下一节的主题。 应用程序工厂的转化工作引出了路由的复杂化。在单脚本应用中，应用程序实例是全局的，所以可以很容易地使用app.route装饰器定义路由。但是现在应用程序在运行时创建，app.route装饰器只有在create_app()调用后才开始存在，这就太迟了。就像路由那样，这些通过app.errorhandler装饰器定义的自定义错误页面处理程序也存在同样的问题。 幸运