设计理念

明确优于隐式

字段不应该仅仅根据字段的名称来假定某些行为。这需要对系统有太多了解，并且容易出现错误。相反，其行为应该基于关键字参数，并且在某些情况下，应该基于字段的类型。

包括所有相关领域逻辑

模型应该封装一个“对象”的各个方面，遵循 Martin Fowler 的 Active Record 设计模式。

这就是为什么在模型类中要同时定义一个模型表现的数据以及关于它的信息（包括其人类可读的名称，默认排序等选项）；所有用于理解给定模型所需的信息都应该存储在模型中。

SQL效率

应该尽可能少地执行SQL语句，并且应该在内部优化语句。

这就是为什么开发者需要显式地调用 save()，而不是由框架静默地在幕后保存东西。

这也是为什么 select_related() QuerySet 方法存在的原因。在查询“每个关联的对象”的常见情况下，它是一个可选的性能提升器。

简洁, 强大的语法

数据库 API 应该允许用尽可能少的语法，来表达丰富、达意的语句。它不应该依赖于导入其他模块或辅助对象。

当必要时, 在幕后插入应该是自动进行的.

每一个对象都应该能够访问所有相关的对象, 系统范围. 这种访问应该是双向的.

当有必要时, 可方便地选择使用原始 SQL 语句

应该认识到数据库 API 只是一个便捷的方法，但并不必须是最终的全部手段。框架应该可以很容易地编写自定义的 SQL——完整的语句，或者仅仅是自定义 WHERE 子句作为 API 调用时的自定义参数。

松耦合

Django 应用中的 URL 不应该与底层 Python 代码耦合。将 URL 与 Python 函数名联系起来是一件很糟糕且丑陋的做法。

按照这些方法，Django URL 系统应该允许同一应用的 URL 在不同的上下文中有所不同。例如，一个网站可以在 /stories/ 中放置故事，而另一个网站则可以使用 /news/。

无限的灵活性

URL 应该尽可能灵活。任何可想到的 URL 设计都应该被允许。

鼓励最佳实践

框架可以做到让开发者简单（或更加简单）地设计出漂亮的，而不是难看的 URL。

在 URL 中应避免出现文件后缀名。

在 URL 中使用 Vignette 式的逗号应该受到严厉的惩罚。

避免冗余

大多数动态网站会使用一些网站整体通用的设计——一个通用的页眉、页脚、导航栏，等等。Django 模板系统应该可以很容易地将这些元素存储在一个地方，从而减少重复的代码。

这是 模板继承 背后的理念。

从 HTML 中解耦

模板系统不应该被设计成只能输出 HTML。它应该同样擅长生成其他基于文本的格式，或者仅仅是纯文本。

XML不应被用于模板语言

使用 XML 引擎去解析模板会在编辑模板的过程中引入很多人为错误，并在模板处理中导致不可接受的开销。

承担设计能力

模板系统不应该有的设计是，使得模板可以在WYSIWYG（所见即所得）编辑器中也能显示得很好，比如 Dreamweaver。因为这是一个非常严重的限制，会让模板的语法不够好。Django 期望模板编写者有能力直接编辑 HTML 文本。

更加直接的处理空格

模板系统不应该用空白符来做神奇的事情。如果模板包含空白符，系统应该在处理文本时处理空格——只是显示它。任何不在模板标签中的空白符都应该显示出来。

不要发明一种编程语言

模板系统的目标不是发明一种编程语言。它的目标是提供足够的具有编程风格的功能，比如分支和循环，这对于做出表现相关的决策是至关重要的。Django 模板语言（DTL） 旨在避免高级逻辑。

Django 模板系统认为模板通常是由 设计师 编写的，而不是 程序员，因此不应该假设他了解 Python。

安全与保障

开箱即用的模板系统禁止包含恶意代码，例如删除数据库记录的代码。

这就是模板系统不允许有任意Python代码的另一个原因。

可扩展性

模板系统应该认识到, 高阶的模板作者可能想扩展它.

这是自定义的模板标签和过滤器背后的理念.

简洁

编写视图应该和编写 Python 函数一样简单。开发人员不应该在函数执行时实例化一个类。

使用请求对象

视图应该能够访问一个请求对象——一个储存关于当前请求的元数据的对象。对象应该直接传递给视图函数，而不是必须从全局变量访问请求数据的视图函数。这使得通过传入“假”请求对象来测试视图变得轻松、干净和容易。

松耦合

视图不应该关心开发人员使用哪种模板——甚至根本不用模板系统。

GET 方法和 POST 方法的区别

GET 和 POST 是不同的；开发人员应该明确地使用其中一个或另一个。框架应该使得 GET 和 POST 数据很容易区分。