Django：“项目” vs“apps” [英] Django: "projects" vs "apps"

问题描述

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

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

我不是重新发明博客或论坛 - 我没有看到我的产品的任何部分在任何情况下都是可重用的。直观地，我会称之为应用程序。然后我可以在一个应用程序文件夹中完成所有工作吗？

如果是这样，那么Django的 project.app 命名空间，我的倾向是使用 myproduct.myproduct ，但当然不允许（但应用程序我' m建筑是我的项目，我的项目是一个应用程序！）。因此，我相信，或许我应该通过为每个重要模型构建一个应用程序来处理Django，但是我不知道在我的架构中绘制边界以将其分割成应用程序的位置 - 我有很多

我希望有一个常见的解决方案...

解决方案

什么是阻止你使用 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脚本等。 / li>
  
• django的管理扩展程序依赖于子目录。因此，适当地命名包是有意义的。

简而言之，有一个约定的原因与任何其他约定相同 - 它当涉及到与您的项目合作的其他人时，可以帮助您。如果我看到 fields.py ，我马上期望它中的代码对django的字段进行子类化，而如果我看到 inputtypes.py 我可能不太清楚这是什么意思，没有看着它。

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?

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

解决方案

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.

这篇关于Django：“项目” vs“apps”的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！