Django:“项目"与“应用程序" [英] Django: "projects" vs "apps"

问题描述

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

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.

项目可以有很多应用.应用程序可以在许多项目之间共享.很好.

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?

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

If so... in terms of Django's project.app namespace, 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.

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

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

推荐答案

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

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

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)，它将被处理.就那么简单.所有这些项目"/应用程序"的东西都只是 python 包.

and so on. Would it help if I said views.py doesn'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.

现在，你应该怎么做?或者更确切地说，我该怎么做?好吧，如果你创建了一个重要的可重用功能，比如一个标记编辑器，那就是当你创建一个顶级应用"时，它可能包含 widgets.py、fields.py、context_processors.py 等 - 您可能想要导入的所有内容.

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.py etc - all things you might want to import.

同样，如果您可以创建一种格式非常通用的博客之类的东西，您可以将其包装在一个应用程序中，使用它自己的模板、静态内容文件夹等，并配置一个 django 项目的实例使用该应用的内容.

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.

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

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 do and you can do it if you really want to. I tend not to, however, for several reasons:

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

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.py I immediately expect code in it to subclass django's field, whereas if I see inputtypes.py I might not be so clear on what that means without looking at it.

这篇关于Django:“项目"与“应用程序"的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！