Django：“项目”与“应用程序”
我有一个相当复杂的“产品”，我准备使用Django构build。 在这里我将避免使用术语“项目”和“应用程序”，因为我不清楚它们在Django中的具体含义。
项目可以有很多应用程序。 应用程序可以在许多项目中共享。 精细。
我不是在重塑博客或论坛 – 我没有看到我的产品的任何部分在任何情况下都是可重用的。 直觉上，我会称之为“应用程序”。 然后，我是否在单个“应用程序”文件夹中完成所有工作？
如果是这样的话 …在Django的project.app命名空间方面，我的倾向是使用myproduct.myproduct ，但当然这是不允许的（但我build立的应用程序是我的项目，我的项目是一个应用程序！ ）。 我因此相信，也许我应该通过为每个“重要”模型构build一个应用程序来处理Django，但是我不知道在我的模式中如何绘制边界以将其分离为应用程序 – 我有很多具有相对复杂关系的模型。
我希望有一个共同的解决scheme，这…
什么是阻止你使用myproduct.myproduct ？ 你需要做到的大致包括这样做：
django-admin.py startproject myproduct cd myproduct mkdir myproduct touch myproduct/__init__.py touch myproduct/models.py touch myproduct/views.py
等等。 如果我说views.py不必被称为views.py ？ 假设你可以在pythonpath上命名一个函数（通常是package.package.views.function_name），它将被处理。 就那么简单。 所有这些“项目”/“应用程序”的东西只是python包。
现在，你应该怎么做？ 或者说，我该怎么做呢？ 那么，如果你创build了一个可重用的function块，比如说一个标记编辑器，那么当你创build一个可能包含widgets.py ， fields.py ， context_processors.py等的“顶级应用程序”时，你可能想要的所有东西import。
同样的，如果你可以用一种非常通用的方式创build一个类似于博客的东西，你可以把它封装在一个应用中，包括它自己的模板，静态内容文件夹等，并且configuration一个django项目的实例来使用它应用的内容。
有没有硬性规定，你必须这样做，但这是框架的目标之一。 事实上，包括模板在内的所有东西都可以让您从一些常见的基础入手，这意味着您的博客应该紧密地融入其他任何设置中，只需照顾自己的部分。
但是，为了解决您的实际问题，是的，没有任何说你不能使用顶级项目文件夹。 这就是应用程序的function ，如果你真的想要的话，你可以做到。 但是，我倾向于不要因为几个原因：
- Django的默认设置不这样做。
- 通常，我想创build一个主应用程序，所以我创build一个，通常称为
website。 不过，在以后的日子里，我可能想为这个网站开发原始的function。 为了使其可移动（无论我是否曾经这样做），我倾向于创build一个单独的目录。 这也意味着我可以放弃所说的function，只需从configuration中取消连接该软件包并删除该文件夹，而不是从全局的urls.py文件夹中删除正确的URL。 - 很多时候，即使当我想要独立的东西，它需要一个地方住，而我照顾它/使之独立。 基本上是上述情况，但对于我打算做通用的东西。
- 我的顶级文件夹通常包含一些其他的东西，包括但不限于wsgi脚本，sql脚本等。
- Django的pipe理扩展依赖于子目录。 所以适当地命名包是有道理的。
简而言之，有一个约定的原因与任何其他约定是一样的 – 当涉及到与你的项目合作的其他人时，这是有帮助的。 如果我看到fields.py我立即希望它的代码子类Django的领域，而如果我看到inputtypes.py我可能不是很清楚这意味着什么，而不看它。
一旦你使用startproject和startappgradle了，没有什么可以阻止你在同一个Python包中组合“project”和“app”。 一个项目实际上只不过是一个settings模块，一个应用程序实际上只不过是一个models模块 – 其他的都是可选的。
对于小型网站来说，拥有这样的东西是完全合理的：
site/ models.py settings.py tests.py urls.py views.py
尝试回答问题：“我的应用程序做了什么？”。 如果你不能用一句话来回答，那么也许你可以用更清晰的逻辑把它分成几个应用程序。
在我开始使用django之后不久，我就读了这个想法，我发现我经常问这个问题，这对我有帮助。
你的应用程序不必是可重用的，它们可以相互依赖，但是它们应该做一件事情。
我发现以下关于django应用程序和项目的博客文章非常有用：
- http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/
- http://web.archive.org/web/20080302205555/www.pointy-stick.com/blog/2007/11/09/django-tip-developing-without-projects/
原则上，使用django来组织产品的源代码有很大的自由。
如果是这样的话…就Django的project.app命名空间而言，我倾向于使用myproduct.myproduct，但当然这是不允许的
没有什么是不允许的。 它的你的项目，没有人限制你。 保持一个合理的名字是可取的。
我没有看到我的产品的任何部分在任何情况下都是可重用的。 直觉上，我会称之为“应用程序”。 然后，我是否在单个“应用程序”文件夹中完成所有工作？
在一个普通的Django项目中，有很多应用程序（contrib应用程序）在每个项目中都被使用。
让我们说，你的项目只有一个任务，只有一个应用程序（我把它命名为main项目围绕它，很难插拔）。 这个项目也一般使用其他应用程序。
现在，如果你说你的项目只使用了一个应用程序（ INSTALLED_APPS='myproduct' ），那么project定义为project.app用法是什么，我想你应该考虑一下几点：
- 除了项目中的应用程序代码（基本静态文件，基本模板，设置….即提供基础）以外，还有很多其他的事情。
- 在一般的project.app方法中，django自动从模型中定义sql模式。
- 使用传统的方法，您的项目将变得更容易。
- 您可以根据需要为url，视图和其他文件定义一些不同的名称，但我没有看到需要。
- 您可能需要在未来添加一些应用程序，这对传统的django项目来说是非常容易的，否则可能会变得同样或者更加困难和繁琐。
就应用程序的大部分工作而言，我认为大部分django项目都是如此。
