Python Django：“项目”与“应用程序”

Django: "projects" vs "apps"

提问by Dolph

I have a fairly complex "product" I'm getting ready to build using Django. I'm going to avoid using the terms "project" and "application" in this context, because I'm not clear on their specific meaning in Django.

我有一个相当复杂的“产品”，我正准备使用 Django 构建。在这种情况下，我将避免使用术语“项目”和“应用程序”，因为我不清楚它们在 Django 中的具体含义。

Projects can have many apps. Apps can be shared among many projects. Fine.

项目可以有许多应用程序。应用程序可以在许多项目之间共享。美好的。

I'm not reinventing the blog or forum - I don't see any portion of my product being reusable in any context. Intuitively, I would call this one "application." Do I then do all my work in a single "app" folder?

我不是在重新发明博客或论坛 - 我认为我的产品的任何部分都无法在任何上下文中重复使用。直观地说，我将其称为“应用程序”。那么我是否在一个“应用程序”文件夹中完成所有工作？

If so... in terms of Django's project.appnamespace, my inclination is to use myproduct.myproduct, but of course this isn't allowed (but the application I'm building is my project, and my project is an application!). I'm therefore lead to believe that perhaps I'm supposed to approach Django by building one app per "significant" model, but I don't know where to draw the boundaries in my schema to separate it into apps - I have a lot of models with relatively complex relationships.

如果是这样……就 Django 的project.app命名空间而言，我倾向于使用myproduct.myproduct，但当然这是不允许的（但我正在构建的应用程序是我的项目，而我的项目是一个应用程序！）。因此，我相信也许我应该通过为每个“重要”模型构建一个应用程序来接近 Django，但我不知道在我的架构中在哪里绘制边界以将其分成应用程序 - 我有很多关系相对复杂的模型。

I'm hoping there's a common solution to this...

我希望有一个通用的解决方案......

采纳答案by JooMing

What is to stop you using myproduct.myproduct? What you need to achieve that roughly consists of doing this:

什么是阻止你使用myproduct.myproduct？您需要实现的大致包括执行以下操作：

django-admin.py startproject myproduct
cd myproduct
mkdir myproduct
touch myproduct/__init__.py
touch myproduct/models.py
touch myproduct/views.py

and so on. Would it help if I said views.pydoesn't have to be called views.py? Provided you can name, on the python path, a function (usually package.package.views.function_name) it will get handled. Simple as that. All this "project"/"app" stuff is just python packages.

等等。如果我说views.py不必打电话会有帮助views.py吗？如果您可以在 python 路径上命名一个函数（通常是 package.package.views.function_name），它将被处理。就那么简单。所有这些“项目”/“应用程序”的东西都只是 python 包。

Now, how are you supposed to do it? Or rather, how might I do it? Well, if you create a significant piece of reusable functionality, like say a markup editor, that's when you create a "top level app" which might contain widgets.py, fields.py, context_processors.pyetc - all things you might want to import.

现在，你该怎么做？或者更确切地说，我该怎么做？好吧，如果你创建一个显著一块可重复使用的功能，好比说一个标记编辑器中，当你创建一个“顶级应用程序”那可能含有widgets.py，fields.py，context_processors.py等等-你可能要导入所有的东西。

Similarly, if you can create something like a blog in a format that is pretty generic across installs, you can wrap it up in an app, with its own template, static content folder etc, and configure an instance of a django project to use that app's content.

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

There are no hard and fast rules saying you must do this, but it is one of the goals of the framework. The fact that everything, templates included, allows you to include from some common base means your blog should fit snugly into any other setup, simply by looking after its own part.

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

However, to address your actual concern, yes, nothing says you can't work with the top level project folder. That's what apps doand you can do it if you really want to. I tend not to, however, for several reasons:

但是，为了解决您的实际问题，是的，没有说您不能使用顶级项目文件夹。这就是应用程序所做的，如果您真的愿意，您可以这样做。但是，出于以下几个原因，我倾向于不这样做：

• 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 extensionsrely on subdirectories. So it makes sense to name packages appropriately.

• Django 的默认设置不会这样做。
• 通常，我想创建一个主应用程序，所以我创建了一个，通常称为website. 但是，以后我可能想为此站点开发原始功能。为了使其可移动（无论我是否做过），我倾向于创建一个单独的目录。这也意味着我可以通过从配置中取消该包的链接并删除该文件夹来删除所述功能，而不是从全局 urls.py 文件夹中复杂地删除正确的 url。
• 很多时候，即使我想让某个东西独立，它也需要一个地方住，同时我照顾它/让它独立。基本上是上述情况，但对于我确实打算使之通用的东西。
• 我的顶级文件夹通常包含其他一些内容，包括但不限于 wsgi 脚本、sql 脚本等。
• django 的管理扩展依赖于子目录。所以适当地命名包是有意义的。

In short, the reason there is a convention is the same as any other convention - it helps when it comes to others working with your project. If I see fields.pyI immediately expect code in it to subclass django's field, whereas if I see inputtypes.pyI might not be so clear on what that means without looking at it.

简而言之，存在约定的原因与任何其他约定相同 - 当涉及到其他人与您的项目一起工作时，它会有所帮助。如果我看到fields.py我立即期望其中的代码子类化 django 的字段，而如果我看到inputtypes.py我可能不看它就不清楚这意味着什么。

回答by JooMing

I've found the following blog posts very useful about django applications and projects:

我发现以下博客文章对 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/

• 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/

In principle, you have a lot of freedom with django for organizing the source code of your product.

原则上，使用 django 可以自由地组织产品的源代码。

回答by Ski

Try to answer question: "What does my application do?". If you cannot answer in a single sentence, then maybe you can split it into several apps with cleaner logic.

尝试回答问题：“我的应用程序有什么作用？”。如果你不能用一句话来回答，那么也许你可以把它分成几个逻辑更清晰的应用程序。

I read this thought somewhere soon after I've started to work with django and I find that I ask this question of myself quite often and it helps me.

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

Your apps don't have to be reusable, they can depend on each other, but they should do one thing.

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

回答by crodjer

If so... in terms of Django's project.app namespace, my inclination is to usemyproduct.myproduct, but of course this isn't allowed

如果是这样......就Django的project.app命名空间而言，我倾向于使用myproduct.myproduct，但这当然是不允许的

There is nothing like not allowed. Its your project, no one is restricting you. It is advisable to keep a reasonable name.

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

I don't see any portion of my product being reusable in any context. Intuitively, I would call this one "application." Do I then do all my work in a single "app" folder?

我认为我的产品的任何部分都无法在任何情况下重复使用。直观地说，我将其称为“应用程序”。那么我是否在一个“应用程序”文件夹中完成所有工作？

In a general django project there are many apps (contrib apps) which are used really in every project.

在一般的 django 项目中，有许多应用程序（contrib 应用程序）在每个项目中都被真正使用。

Let us say that your project does only one task and has only a single app (I name it mainas thethe project revolves around it and is hardly pluggable). This project too still uses some other apps generally.

假设您的项目仅执行一项任务并且只有一个应用程序（我将其命名main为项目围绕它展开并且几乎不可插入）。这个项目也仍然普遍使用其他一些应用程序。

Now if you say that your project is using just the one app (INSTALLED_APPS='myproduct') so what is use of projectdefining the project as project.app, I think you should consider some points:

现在，如果您说您的项目仅使用一个应用程序 ( INSTALLED_APPS='myproduct') 那么project将项目定义为 有什么用project.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.

• 除了项目中的应用程序之外，还有许多其他代码可以处理（基本静态文件、基本模板、设置……即提供了基本信息）。
• 在一般的 project.app 方法中，django 自动从模型定义 sql 模式。
• 使用传统方法构建您的项目会容易得多。
• 您可以根据需要为 url、视图和其他文件定义一些不同的名称，但我认为没有必要。
• 您可能需要在未来添加一些应用程序，这对于传统的 django 项目来说非常容易，否则它可能会变得同样或更加困难和乏味。

As far as most of the work being done in the app is concerned, I think that is the case with most of django projects.

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

回答by claymation

Once you graduate from using startprojectand startapp, there's nothing to stop you from combining a "project" and "app" in the same Python package. A project is really nothing more than a settingsmodule, and an app is really nothing more than a modelsmodule—everything else is optional.

一旦你从使用startprojectand毕业startapp，没有什么可以阻止你在同一个 Python 包中组合“项目”和“应用程序”。一个项目实际上只不过是一个settings模块，而一个应用程序实际上也只不过是一个models模块——其他一切都是可选的。

For small sites, it's entirely reasonable to have something like:

对于小型网站，使用以下内容是完全合理的：

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

回答by Qback

Here Django creators points out that difference themselves. I think that thinking about Apps as they have to be reusablein other projects is good. Also a good way of thinking about Apps in Django provide modern web applications.

Django 的创建者在这里指出了这种差异。我认为考虑应用程序因为它们必须在其他项目中可重用是好的。Django 提供现代 Web 应用程序也是思考应用程序的好方法。

Imagine that you are creating big dynamicweb app basing on JavaScript.

想象一下，您正在创建基于JavaScript 的大型动态Web 应用程序。

You can create then in django App named e.g "FrontEnd" <-- in thins app you will display content.

然后您可以在名为“FrontEnd”的 django 应用程序中创建 <-- 在 Thins 应用程序中，您将显示内容。

Then you create some backend Apps. E.g App named "Comments" that will store user comments. And "Comments" App will not display anything itself. It will be just API for AJAX requests of your dynamicJSwebsite.

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

In this way you can always reuse your "Comments" app. You can make it open source without opening source of whole project. And you keep clean logicof your project.

通过这种方式，您可以随时重复使用您的“评论”应用程序。您可以在不开源整个项目的情况下将其开源。并且您保持项目的清晰逻辑。