Question

我目前正在浏览Django网站上的教程。完成以下命令后：

python manage.py startapp民意调查

它创建了以下结构：

polls/
    __init__.py
    models.py
    tests.py
    views.py

在我阅读教程时，我发现视图文件可能会扩展到这个庞大的不完整的整体文件，该文件在整个Web应用程序中都有所有操作。

有没有办法将此文件分解为内聚类或文件？我尝试将settings.py和url.py更改为指向不同的目录，但是生成文件结构的脚本在创建文件时会显示“views”模块，而我看不到某种方式从脚本中更改/覆盖此行为。

Answer 1

您可以采用与此博客条目拆分模型的方式类似的方式拆分视图

例如

/myapp

    * /views
          o __init__.py
          o bar.py
          o foo.py

在__init__.py文件中使用适当的import语句

这可能适合扩展应用。此外，视图在结构化方式上比模型更灵活，因此您可以执行后端/成员/前端/模块或仅管理admin_views.py等。

Answer 2

视图函数不必位于views.py中，只要它们在urls.py中正确映射，它们就可以在任何位置。因此，您可以自己组织项目。

但似乎生成文件结构的脚本在创建文件时会创建一个“views”模块，而我看不到从脚本中更改/覆盖此行为的方法。

您可以完全忽略该脚本及其生成的内容。它在幕后没有做任何神奇的事情;它只是为你创建这些文件。

Answer 3

您为项目创建的每个应用程序都有自己的views.py文件（假设它使用视图），因此您无需担心它会变成单一的。

确保专注于保持应用的功能。

来自Django文档：

项目与应用

a之间有什么区别   项目和应用程序？一个应用程序是一个Web   做某事的应用程序 -   例如，博客系统，数据库   公共记录或简单的民意调查应用。一个   项目是一个集合   配置和应用程序   特定的网站。一个项目可以   包含多个应用。一个应用程序可以   在多个项目中。

Answer 4

我最近在那个教程中工作过。我曾经想过，大多数“核心”逻辑会进入其他支持文件中的各种类或方法。那么views.py将包含设置和执行方法的基本调用。

鉴于这种设计，我希望单个视图函数最终可能会有3到5行代码。设置，执行方法和返回。

基本上，我的意思是Facade pattern的实现。

我希望教程避免使用这种方法，因为它增加了重定向级别（误导？），这使得介绍人员更难以遵循代码。

Answer 5

我做的一件事就是让我的应用程序的观点更加紧凑，这是我非常积极地考虑我的观点。我讨厌两次写任何代码，所以这对我来说很自然。我可以随时随地使用通用视图来执行所需的操作。我的视图功能的很大一部分是装饰器，它们对需要它的视图执行常见操作。

例如，我有一个post_limit装饰器，用于检查用户是否最近修改了某个模型中的任何实例（视图中的可配置视图），如果有，则会产生错误，作为防洪手段。

事实上，许多视图的工作方式非常相似，它们甚至没有自己的函数体，我只是使用适当的装饰器来包装通用视图，并且获得很多自定义代码的唯一视图是聚合类型的站点，例如登陆页面，以微妙的方式收集大量不同的信息，使它们看起来“恰到好处”