python函数myproduct_关于python：Django：“项目”与“应用程序”

我有一个相当复杂的"产品"，我准备用django来构建它。我将避免在本文中使用术语"项目"和"应用程序"，因为我不清楚它们在Django中的具体含义。

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

我不是在重新设计博客或论坛-我不认为我的产品的任何部分在任何上下文中都是可重用的。凭直觉，我会称这一个为"应用程序"，然后我会在一个"应用程序"文件夹中完成所有工作吗？

如果是这样…就django的project.app名称空间而言，我倾向于使用myproduct.myproduct，但这当然是不允许的(但我正在构建的应用程序是我的项目，而我的项目是应用程序！)因此，我相信，也许我应该通过为每个"重要"模型构建一个应用程序来接近Django，但我不知道在我的模式中从何处划出界限，将其分离为应用程序-我有很多模型具有相对复杂的关系。

我希望有一个共同的解决办法…

文档解释了"应用程序"和"项目"之间的区别，这里是：docs.djangoproject.com/en/dev/ref/applications/&hellip；

一旦您从使用startproject和startapp中毕业，就没有什么可以阻止您在同一个python包中组合"项目"和"应用程序"。一个项目实际上只不过是一个settings模块，而一个应用程序实际上只不过是一个models模块，其他一切都是可选的。

对于小型网站，完全合理的做法是：

site/

models.py

settings.py

tests.py

urls.py

views.py

+1小结：project has settings.py，app has models.py。它们是相同的层次结构。我以前认为项目比应用程序高一级，我想我错了。

@Claymation，为了允许"python manage.py makemigrations"或"python manage.py migrate"在"我的产品"目录中查看"models.py"文件，设置(作为应用程序)中应该包括什么？

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.

号

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

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

+1遵循Unix的理念：faqs.org/docs/artu/ch01s06.html

在设计我自己的应用程序时，我还是有点挣扎。我觉得我的主应用程序有点重，但同时，我不能将它重构成类似于松散耦合的东西的任何东西。我倾向于认为，如果我的主要实体仍然严重依赖于彼此，并且没有必要在地平线上重用或泛化，那么将它们分离并不是真正的改进。我倾向于用"不要过早重构"来解释"不要过早优化"

是什么阻止你使用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.functionu name)，它将被处理。就这么简单。所有这些"项目"/"应用"的东西都只是python包。

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

类似地，如果你可以创建一个类似于博客的格式，这种格式在安装过程中非常通用，你可以用自己的模板、静态内容文件夹等将它包装在一个应用程序中，并配置一个Django项目的实例来使用该应用程序的内容。

没有硬性和快速的规则规定必须这样做，但这是框架的目标之一。事实上，所有的东西，包括模板，都允许你从一些共同的基础上包括，这意味着你的博客应该适合任何其他的设置，只需关注它自己的部分。

但是，为了解决您的实际问题，是的，没有什么可以说明您不能使用顶级项目文件夹。这就是应用程序所做的，如果你真的想做的话，你也可以做。然而，我倾向于不这样做，原因有几个：

Django的默认设置不起作用。

通常，我想创建一个主应用程序，所以我创建了一个，通常称为website。但是，在以后的某一天，我可能只想为这个站点开发原始的功能。为了使它可移动(无论我是否做过)，我倾向于创建一个单独的目录。这也意味着我可以通过将包从配置中取消链接并删除文件夹来删除上述功能，而不是复杂地从global urls.py文件夹中删除正确的URL。

很多时候，即使我想让某个事物独立，它也需要在我照顾它/使它独立的同时，生活在某个地方。基本上是上面的情况，但对于我想让通用的东西。

我的顶级文件夹通常包含一些其他内容，包括但不限于wsgi脚本、SQL脚本等。

Django的管理扩展依赖于子目录。所以恰当地命名包是有意义的。

小精灵

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

+1…"是什么阻止你使用myproduct.myproduct？"-我想，Django的"startapp"命令实际上会阻止你成为惯例。我喜欢约定，特别是在团队工作的背景下，但我更喜欢理解它们背后的逻辑：)

@多夫啊，是吗？自从我第一次使用它以来，我就没有使用过它，因为我有自己的命令来创建一个项目，该项目首先创建模型，然后自动为这些模型生成CRUD内容。不过，是的，惯例是好的。我遵循姜戈的习俗，如果仅仅是因为在很大程度上讲它们是有意义的。

我要补充的是，对项目和其中的应用程序使用相同的名称也会导致manage.py出现问题，导致它无法正确导入项目设置。这发生在我身上，我通过将应用程序重构为myproduct_app的效果来解决它。

我发现以下关于django应用程序和项目的博客文章非常有用：

http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/

http://web.archive.org/web/20080302205555/www.pointy-stick.com/blog/2007/11/09/django-tip-developing-without-projects/

小精灵

原则上，Django可以自由地组织产品的源代码。

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

号

没有什么是不允许的。这是你的计划，没有人限制你。保持一个合理的名字是明智的。

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项目中，有许多应用程序(contrib应用程序)在每个项目中都被真正使用。

假设您的项目只执行一项任务，只有一个应用程序(我将其命名为main，因为该项目围绕它旋转，几乎不可插入)。这个项目通常还使用其他一些应用程序。

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

除了项目中的应用程序之外，还有许多其他的代码可以处理(基本静态文件、基本模板、设置……即提供基础)。

在general project.app方法中，django自动从模型定义SQL模式。

您的项目将更容易用常规方法构建。

您可以根据需要为URL、视图和其他文件定义一些不同的名称，但我不认为有必要。

您可能需要在将来添加一些应用程序，这对于传统的Django项目来说非常容易，否则它可能变得同样或更加困难和乏味。

小精灵

就应用程序中所做的大部分工作而言，我认为大多数Django项目都是这样。

+1，尤其是对于main公约——对于这样一个最初的项目，这对我来说很有意义。我计划稍后添加"可重用"的应用程序，但现在这已经超出了我的关注范围。

在这里，Django的创造者们自己指出了这一区别。我认为考虑应用程序，因为它们必须在其他项目中可重用，这是很好的。同时，Django的应用程序也是一种很好的思考方式，它提供了现代的Web应用程序。

假设您正在基于javascript创建大型动态Web应用程序。

您可以在django应用程序中创建名为"frontend"

然后创建一些后端应用程序。例如名为"注释"的应用程序，它将存储用户注释。"评论"应用程序本身不会显示任何内容。它只是动态JS网站的Ajax请求的API。

通过这种方式，你可以一直重复使用你的"评论"应用程序。您可以使它成为开放源代码，而不必打开整个项目的源代码。并且你要保持项目的清晰逻辑。