3

我在愚蠢的练习应用程序中使用 Flask-OpenID 进行用户登录。

首先要做的是创建一个 openid 对象，稍后用于装饰登录处理程序（和其他东西）：

oid = flask.ext.openid.OpenID(app, '/path/to/store')

@oid.loginhandler
def login():
    ...

@oid.after_login
def after_login():
    ...

但是，我想在我的应用程序__init__.py文件中初始化 Flask-OpenID，但在其他文件中使用 OpenId 对象oid，例如我的应用程序views.py文件和可能的其他文件。执行此操作的预期方法是什么？烧瓶开发人员通常如何使oid应用程序具有全局性？

在这个类似的问题中，SQLAlchemy 对象被移动到models模块中，但在应用程序设置期间在其他地方初始化，这很有意义，因为该db对象与模型耦合。OpenID 对象遵循相同的模式。但我不想oid投入views.py；它显然不属于那里。那么你会把它放在哪里呢？我可以想到解决方案，但我想知道烧瓶开发人员通常会做什么。这里有一些想法：

  • oid在那里放入__init__.py并初始化它。在这个选项中，如何oid在应用模块的另一部分访问？

  • 为与 Flask-OpenID 和 Flask-Login 关联的对象和方法创建一个auth.py文件。然后auth.oid可以在应用程序的任何地方工作。然后我是否为每个没有直接耦合到其他地方的扩展创建一个新文件？这是矫枉过正，还是扩大规模和保持井井有条的正确模式？

  • 或者，为所有这些小扩展对象创建一个文件，可能称为globals.py或exts.py. 这看起来很尴尬和笨拙。还是大多数烧瓶应用程序最终都有一个随机桶来存放所有其他只需要位于某个地方的垃圾？

4

1 回答 1

1

这三个选项有各种权衡（如您所见）：

  1. 创建- 这会auth导致__init__.py您的视图和您的基础应用程序之间的循环引用 - 它可以工作，但它会使其更难以考虑（因为移动两个原本不相关的导入可能会导致错误）。
  2. 创建一个单独的模块来处理单独的关注点 - 这避免了循环引用问题并为更大的项目增加了清晰度（“啊，这是处理身份验证的代码所属的地方”）。另一方面，带有几个小扩展的小项目最终可能会出现类似 Java 的模块爆炸。
  3. 创建一个单独的模块来初始化应用程序中使用的所有 Flask 扩展。这也避免了循环引用问题，并防止小型项目不必要地增加模块。然而，在较大的项目中，这样的模块会变成一个大泥球。（“这是配置身份验证、平面文件处理和错误处理的地方”）。

还有第四个选项 - 添加auth到您的视图层，因为您的身份验证方式特定于您的应用程序逻辑（而不是您的域模型，例如）。

我建议完全避免＃1（跳过“两个模块”阶段直接进入“三个或更多模块阶段”的额外成本可以忽略不计）。其余三个选项中的哪一个适合您的项目，具体取决于项目和从事该项目的开发人员。

于 2014-06-11T03:06:21.363 回答