Django:“项目"与“应用程序"相比
问题描述
我准备使用 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.
我没有重新发明博客或论坛 - 我看不到我的产品的任何部分在任何情况下都可以重复使用.直观地说，我将其称为应用程序".然后我是否在一个app"文件夹中完成所有工作?
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.
相关文章