我发现下面这篇关于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-admin.py startproject myproduct
cd myproduct
mkdir myproduct
touch myproduct/__init__.py
touch myproduct/models.py
touch myproduct/views.py

等等。如果我说views。py不必叫views。py会不会有用?只要你能在python路径上命名一个函数(通常是package.package.views.function_name)，它就会被处理。就这么简单。所有这些“project”/“app”的东西都只是python包。

现在，你该怎么做?或者说，我该怎么做呢?好吧，如果你创建了一个重要的可重用功能，比如一个标记编辑器，那就是当你创建一个“顶级应用程序”时，它可能包含widget .py, fields.py, context_processors.py等——所有你可能想导入的东西。

类似地，如果你可以创建一个类似博客的东西，在安装中使用一种非常通用的格式，你可以把它包装在一个应用程序中，有自己的模板，静态内容文件夹等，并配置一个django项目的实例来使用该应用程序的内容。

没有硬性规定说您必须这样做，但这是框架的目标之一。事实上，所有的东西，包括模板，都允许你从一些共同的基础上包含，这意味着你的博客应该适合任何其他的设置，只需要照顾自己的部分。

但是，为了解决您的实际问题，是的，没有人说您不能使用顶级项目文件夹。这就是应用程序所做的，如果你真的想做，你可以做到。然而，我倾向于不这样做，原因如下:

Django's default setup doesn't do it. Often, I want to create a main app, so I create one, usually called website. However, at a later date I might want to develop original functionality just for this site. With a view to making it removable (whether or not I ever do) I tend to then create a separate directory. This also means I can drop said functionality just by unlinking that package from the config and removing the folder, rather than a complex delete the right urls from a global urls.py folder. Very often, even when I want to make something independent, it needs somewhere to live whilst I look after it / make it independent. Basically the above case, but for stuff I do intend to make generic. My top level folder often contains a few other things, including but not limited to wsgi scripts, sql scripts etc. django's management extensions rely on subdirectories. So it makes sense to name packages appropriately.

简而言之，有一个约定的原因和任何其他约定是一样的——当涉及到其他人处理您的项目时，它会有所帮助。如果我看到fields.py，我立即期望它的代码子类django的字段，而如果我看到inputtypes.py，我可能不清楚这意味着没有看它。

试着回答问题:“我的 应用程序做了什么?”。如果你不能回答 用一句话，也许你可以 用cleaner把它分成几个应用程序 逻辑。

在我开始使用django后不久，我在某个地方读到了这个想法，我发现我经常问自己这个问题，这对我很有帮助。

你的应用程序不必是可重用的，它们可以相互依赖，但它们应该做一件事。

如果是这样的话……在Django的项目方面。应用命名空间，我倾向于使用emyproduct。我的产品，当然这是不允许的

没有什么是不允许的。这是你的项目，没有人限制你。保留一个合理的名字是明智的。

我没有看到我的产品的任何部分在任何情况下是可重用的。直观地说，我将其称为“应用程序”。那么我是否将所有工作都放在一个“app”文件夹中?

在一个普通的django项目中，有很多应用程序(contrib apps)在每个项目中都会用到。

让我们假设你的项目只做一项任务，只有一个应用程序(我把它命名为main，因为整个项目都围绕着它，几乎是不可插入的)。这个项目也仍然使用一些其他应用程序一般。

现在如果你说你的项目只使用一个应用程序(INSTALLED_APPS='myproduct')，那么项目定义项目为项目的用途是什么。app，我认为你应该考虑以下几点:

There are many other things that the code other than the app in a project handles (base static files, base templates, settings....i.e. provides the base). In the general project.app approach django automatically defines sql schema from models. Your project would be much easier to be built with the conventional approach. You may define some different names for urls, views and other files as you wish, but I don't see the need. You might need to add some applications in future which would be real easy with the conventional django projects which otherwise it may become equally or more difficult and tedious to do.

就应用程序中所做的大部分工作而言，我认为大多数django项目都是如此。

一旦你学会了使用startproject和startapp，就没有什么能阻止你在同一个Python包中组合“project”和“app”了。一个项目实际上只不过是一个设置模块，而一个应用程序实际上只不过是一个模型模块——其他一切都是可选的。

对于小型网站来说，这样做是完全合理的:

site/
    models.py
    settings.py
    tests.py
    urls.py
    views.py

在这里，Django的创建者们自己指出了这种差异。 我认为考虑应用程序必须在其他项目中可重用是件好事。Django提供了现代的web应用程序，这也是一种很好的思考方式。

假设你正在创建基于JavaScript的大型动态web应用。

你可以在django中创建一个名为“FrontEnd”的应用程序——在这个应用程序中你会显示内容。

然后创建一些后端应用程序。示例应用程序命名为“评论”，将存储用户的评论。“评论”应用程序本身不会显示任何东西。它只是一个API，用于动态JS网站的AJAX请求。

这样你就可以重用你的“评论”应用程序。你可以让它开源，而不用开放整个项目的源代码。这样你就能保持清晰的项目逻辑。