49

我真的在为整个应用程序的想法而苦苦挣扎。我阅读了很多教程和风格指南，我知道我应该尝试创建专门的应用程序，只做一件事。在查看一些简单的教程项目时，这一切都是有道理的，但是一旦涉及到一个复杂的现实生活项目，我发现自己无法确定应该如何在不同的应用程序之间划清界限。

问题之一是，我希望有一个站点（或多个站点），用户可以在其中看到很多不同的内容。遵循应用程序设计规则时，应该来自不同应用程序的东西。我怎么会意识到这样的事情？我的第一个想法是创建一个名为ui的应用程序，它只处理实际导致模板的所有视图，所有其他应用程序都提供模型和辅助函数。但我担心这个ui应用程序会变得很大。

给你一个小例子：让我想要一个用户可以执行以下任务的站点：

  • 选择一个主题
  • 为所选主题设置一些选项
  • 上传与他的帐户关联的文件
  • 将一些上传的文件分配给主题
  • 录制一些与主题相关的音频

现在，我将创建三个应用程序：

  1. 主题（包含主题模型和一些相关模型）
  2. 资源（包含资源模型，处理上传）
  3. 音频（处理所有音频记录和处理的东西）

但是，我需要某种应用main程序ui来处理这些应用程序如何交互并创建实际站点，所有应用程序都以某种方式参与其中。

那么，有没有“正确”的方法来做到这一点？或者有什么我可以使用的模式吗？即使我已经阅读了很多，我也希望能提供有关该主题的优质资源的链接。

4

2 回答 2

19

你只需要确保你的结构对你有意义。

不需要为绑定到项目逻辑的另一部分的每个功能创建一个新应用程序。

可重用的应用程序是一个完全不同的故事，它们的代码在某种程度上应该不知道实现。

看看Django 的结构以获得灵感

您的示例的可能布局：

project_root/
    project/
        __init__.py
        settings.py
        urls.py
        templates/
            app1/  # override stuff
        static/
        media/
    app1/
        __init__.py
        admin/  # as a package
            __init__.py
            subjects.py
            resources.py
            # etc
        models/  # as a package
            subjects.py
            resources.py
            # etc
        managers/
            __init__.py
            subjects.py
            resources.py
            # etc
        services/
            __init__.py
            audio.py  # upload handler etc
        views/
            __init__.py
            subjects.py
        urls/
            __init__.py
            subjects.py
        templates/
            app1/
                subject_list.html  # override at project level
        static/
            app1/
                css/
                    subject.css  # override at project level
    app2/
        __init__.py
        models.py  # holds a Member model or whatever you require
    manage.py
于 2013-08-16T10:25:00.673 回答
13

我认为划分应用程序的最佳方式大致等同于在面向对象的编程语言上划分类的方式。您可以分别考虑模型和视图，而不是变量和方法：

模型是对象的状态，视图用于查看对象的状态并与之交互。

我的经验法则是，创建应用程序是否有助于封装一组特定的模型？如果是这样，那么我尝试创建它。

于 2013-08-16T10:30:56.657 回答