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

发布于 2024-10-15 21:15:12 字数 486 浏览 3 评论 0原文

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

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

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

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

我希望有一个共同的解决方案......

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

烂人 2024-10-22 21:15:12

一旦您不再使用 startproject 和 startapp，就没有什么可以阻止您在同一个 Python 包中组合“项目”和“应用程序”。项目实际上只不过是一个 settings 模块，而应用程序实际上只不过是一个 models 模块 - 其他所有内容都是可选的。

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

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

Once you graduate from using startproject and 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 settings module, and an app is really nothing more than a models module—everything else is optional.

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

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

回复收藏 0 原文

穿越时光隧道 2024-10-22 21:15:12

尝试回答问题：“我的
申请做什么？”。如果您无法回答
用一句话来说，那么也许你可以
用cleaner把它分成几个应用程序
逻辑。

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

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

回复收藏 0 原文

耶耶耶 2024-10-22 21:15:12

是什么阻止您使用 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 会有帮助吗？如果您可以在 python 路径上命名一个函数（通常是 package.package.views.function_name），它将被处理。就这么简单。所有这些“项目”/“应用程序”的东西只是 python 包。

现在，你该怎么做呢？或者更确切地说，我该怎么做？好吧，如果您创建了一个重要的可重用功能，例如标记编辑器，那么您就创建了一个“顶级应用程序”，其中可能包含 widgets.py、fields.py、context_processors.py 等 - 您可能想要导入的所有内容。

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

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

但是，为了解决您的实际问题，是的，没有什么表明您不能使用顶级项目文件夹。 这就是应用程序的作用，如果您确实愿意，也可以做到。然而，出于以下几个原因，我倾向于不这样做：

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

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

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

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.

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.

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'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.

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.

回复收藏 0 原文