问题:Django:“项目”与“应用”

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

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

我不是在改造博客或论坛-我看不到产品的任何部分在任何情况下都可以重用。凭直觉,我将其称为“应用程序”。然后,我是否将所有工作都放在一个“ app”文件夹中?

如果是的话 …就Django的project.app命名空间而言,我倾向于使用myproduct.myproduct,但这当然是不允许的(但是我正在构建的应用程序是我的项目,而我的项目是一个应用程序!)。因此,我相信我可能应该通过为每个“重要”模型构建一个应用程序来接近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?

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…


回答 0

什么是阻止您使用的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.pyfields.pycontext_processors.py等等-你可能要导入所有的东西。

同样,如果您可以创建类似博客这样的东西,并且其格式在安装过程中非常通用,则可以将其包装在应用程序中,包括其自己的模板,静态内容文件夹等,并配置Django项目的实例以使用该模板应用程序的内容。

没有硬性规定可以执行此操作,但这是框架的目标之一。包括模板在内的所有内容均允许您从某个通用基础上进行包含,这意味着您的博客应该仅通过照顾自己的一部分就可以紧密地适合任何其他设置。

但是,要解决您的实际问题,是的,没有什么说不能使用顶层项目文件夹的。这就是应用程序要做的,如果您确实愿意,您可以这样做。但是,由于以下几个原因,我倾向于不这样做:

  • Django的默认设置不执行此操作。
  • 通常,我想创建一个主应用程序,因此我创建了一个通常称为的应用程序website。但是,以后我可能只想为此站点开发原始功能。为了使它可移动(无论我是否曾经做过),我倾向于然后创建一个单独的目录。这也意味着我可以仅通过从配置中取消该程序包的链接并删除文件夹来删除所述功能,而不是从全局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.


回答 1

一旦您从使用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

回答 2

尝试回答问题:“我的应用程序做什么?”。如果您无法用一个句子回答,那么您可以将其拆分为具有更清晰逻辑的多个应用程序。

在开始与django合作后不久,我在某个地方读了这个想法,发现我经常问自己这个问题,对我有帮助。

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

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.

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


回答 3

我发现以下博客文章对Django应用程序和项目非常有用:

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

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

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


回答 4

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

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

我看不到产品的任何部分在任何情况下都可以重用。凭直觉,我将其称为“应用程序”。然后,我是否将所有工作都放在一个“ app”文件夹中?

在一般的django项目中,有很多应用程序(contrib应用程序)在每个项目中都真正使用。

让我们说您的项目仅执行一项任务,并且只有一个应用程序(我将其命名为 main为该项目围绕它展开并且几乎不可插入)。该项目通常也仍然使用其他一些应用程序。

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

  • 除项目中的应用程序外,代码还可以处理许多其他事情(基本静态文件,基本模板,设置…即提供基本信息)。
  • 在一般的project.app方法中,django自动从模型定义sql模式。
  • 使用常规方法可以更轻松地构建您的项目。
  • 您可以根据需要为url,视图和其他文件定义一些不同的名称,但我认为没有必要。
  • 您将来可能需要添加一些应用程序,而这些应用程序对于常规的django项目而言确实很容易,否则可能会变得同等或更困难,乏味。

就应用程序中完成的大多数工作而言,我认为大多数Django项目就是这种情况。

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

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.

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

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

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

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.


回答 5

在这里Django的创建者自己指出了这种差异。我认为,考虑必须在其他项目中重复使用的 Apps 是很好的。考虑Django中的Apps也是一种提供现代Web应用程序的好方法。

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

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

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

这样,您随时可以重复使用“评论”应用。您可以将其开源,而无需打开整个项目的源码。这样您就可以保持项目的逻辑清晰。

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

Imagine that you are creating big dynamic web app basing on JavaScript.

You can create then in django App named e.g “FrontEnd” <– in thins app you will display content.

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 dynamic JS website.

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 logic of your project.


声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。