我注意到对于 Django 中的“应用程序”的含义有很多混淆,这在很大程度上是因为文档只用更多抽象来解释这个抽象概念。(http://docs.djangoproject.com/en/dev/intro/tutorial01/)
什么是应该变成应用程序的东西的具体例子?
我注意到对于 Django 中的“应用程序”的含义有很多混淆,这在很大程度上是因为文档只用更多抽象来解释这个抽象概念。(http://docs.djangoproject.com/en/dev/intro/tutorial01/)
什么是应该变成应用程序的东西的具体例子?
我认为 Django“应用程序”是网站的高级功能。假设有一个网站提供论坛、生活聊天、常见问题解答和图片库。我将为这 4 个功能中的每一个创建一个单独的 Django 应用程序。每个应用程序都可以拥有,但不一定必须拥有,它自己的模型、视图、模板(以及潜在的中间件和其他东西),它们都密切相关并服务于单一的高级目的。
我就是这样解释的。
James Bennett 的这个演讲应该回答你所有的问题:)
的整体django.contrib
。请参阅http://docs.djangoproject.com/en/dev/ref/contrib/了解每个应用程序的功能。
基本上任何可以归结为独立于项目的实用程序的功能集都应该成为可重用的应用程序。
我目前正在使用 Python/Django 构建分布式应用程序。任何特定服务器都需要引用一组核心功能,以及针对其情况的特定功能。有些部分需要完整的模型-视图-模板系统,有些则只需要共享模型。应用程序的一部分将使用内存数据库,而应用程序的其余部分将使用企业级数据库。
我选择将此应用程序构建为一组“应用程序”,可以通过使用“智能”settings.py
和urls.py
脚本来打开或关闭。“核心”应用程序将仅具有整个应用程序通用的模型(但没有视图或模板)。“webcore”应用程序将添加在所有提供 Web UI 的应用程序中通用的视图和模板。其他应用程序将拥有自己的模型,以及适当的视图和模板。一些应用程序只会实现后台服务,因此不需要视图或模板。
settings.py
通过在和脚本中组合多个应用程序urls.py
,我可以构建和测试应用程序的小部分,而无需处理整个应用程序的复杂性。我还可以将应用程序的一部分分发到多个服务器(用于扩展或利用独特的资源)。如果我使用单个“应用程序”构建这个应用程序,我会失去很多灵活性。