Django2.0手册:设计理念

松耦合¶

Django 栈的基本目标是降低耦合度同时加强聚合度。框架里的不同层（Layers）不应该知道对方的代码，除非它们确实需要。

例如，模板系统不需要知道用户的 Web 请求，数据库层不需要了解如果显示数据，而视图并不关心程序员所使用的模板系统。

尽管为了方便 Django 带有一个完整的堆栈，但堆栈的各个部分尽可能独立于另一个堆栈。

更少的代码¶

Django应用的代码应该尽可能地精简，Django应该充分利用Python的动态能力，比如自省机制（introspection）

快速开发¶

在 21 世纪，Web 框架的核心一点是让 Web 开发中枯燥的事情处理得更加快速，Django 可以做到快速的 Web 开发。

不要重复地造轮子 (DRY)¶

每个独特的概念或数据片应该存在且只存在于一个地方。避免冗余，做好标准化。

合理的框架应该从尽可能少的信息中推断出尽可能多的需求。

明确优于隐式¶

这是在 PEP 20 列出的核心 Python 原则，这意味着 Django 不应该使用太多的“魔术”。除非有一个很好的理由，否则不应该出现魔术。只有当魔术创造了巨大的便利，并且使用其他方式难以实现时，它才值得使用，而且它的实现方式并不会让试图学习如何使用该功能的开发人员感到困惑。

一致性¶

框架应在所有层级上保持一致。一致性适用于从低级（Python 的编码风格）到高级（使用 Django 的“经验”）的所有内容。

明确优于隐式¶

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

包括所有相关领域逻辑¶

模型应该封装一个“对象”的各个方面，遵循 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 式的逗号应该受到严厉的惩罚。

定义URL¶

技术上，foo.com/bar 和 foo.com/bar/ 是两条不同的 URL，搜索引擎爬虫（以及某些 Web 流量分析工具）会将其视为独立的页面。Django 会将其转为 “标准” 的 URL，让搜索引擎爬虫正确识别。

详细请参考：setting:APPEND_SLASH setting.

演示不同的逻辑¶

We see a template system as a tool that controls presentation and
presentation-related logic — and that’s it. The template system shouldn’t
support functionality that goes beyond this basic goal.

避免冗余¶

The majority of dynamic websites use some sort of common sitewide design —
a common header, footer, navigation bar, etc. The Django template system should
make it easy to store those elements in a single place, eliminating duplicate
code.

This is the philosophy behind template inheritance.

从 HTML 中解耦¶

The template system shouldn’t be designed so that it only outputs HTML. It
should be equally good at generating other text-based formats, or just plain
text.

XML不应被用于模板语言¶

Using an XML engine to parse templates introduces a whole new world of human
error in editing templates — and incurs an unacceptable level of overhead in
template processing.

假设设计能力¶

The template system shouldn’t be designed so that templates necessarily are
displayed nicely in WYSIWYG editors such as Dreamweaver. That is too severe of
a limitation and wouldn’t allow the syntax to be as nice as it is. Django
expects template authors are comfortable editing HTML directly.

对待空格很明显¶

The template system shouldn’t do magic things with whitespace. If a template
includes whitespace, the system should treat the whitespace as it treats text
— just display it. Any whitespace that’s not in a template tag should be
displayed.

不要发明一种编程语言¶

The goal is not to invent a programming language. The goal is to offer just
enough programming-esque functionality, such as branching and looping, that is
essential for making presentation-related decisions. The Django Template
Language (DTL) aims to avoid advanced logic.

The Django template system recognizes that templates are most often written by
designers, not programmers, and therefore should not assume Python
knowledge.

安全与保障¶

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

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

可扩展性¶

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

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

简洁¶

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

使用请求对象¶

Views should have access to a request object — an object that stores metadata
about the current request. The object should be passed directly to a view
function, rather than the view function having to access the request data from
a global variable. This makes it light, clean and easy to test views by passing
in “fake” request objects.

松耦合¶

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

GET方法和POST方法的区别¶

GET and POST are distinct; developers should explicitly use one or the other.
The framework should make it easy to distinguish between GET and POST data.

更少的代码¶

A cache should be as fast as possible. Hence, all framework code surrounding
the cache backend should be kept to the absolute minimum, especially for
get() operations.

一致性¶

The cache API should provide a consistent interface across the different
cache backends.

可扩展性¶

The cache API should be extensible at the application level based on the
developer’s needs (for example, see Cache key transformation).