本文档解释了Django开发人员在创建框架时使用的一些基本原理。它的目标是解释过去和指导未来。
Django的一个基本目标是 loose coupling and tight cohesion . 除非绝对必要，否则框架的各个层不应该互相“了解”。
例如，模板系统对Web请求一无所知，数据库层对数据显示一无所知，而视图系统并不关心程序员使用哪个模板系统。
尽管Django为方便起见提供了一个完整的堆栈，但堆栈的各个部分尽可能独立于另一个。
Django应用程序应该使用尽可能少的代码；它们应该缺少样板文件。Django应该充分利用Python的动态功能，比如内省。
21世纪Web框架的重点是让Web开发的繁琐方面变得更快。Django应该可以实现令人难以置信的快速Web开发。
每一个不同的概念和/或数据块都应该只存在一个地方。冗余是坏的。正常化是好的。
框架，在合理的范围内，应该尽可能少地推导。
这是中列出的核心python原则 PEP 20 这意味着 Django 不应该做太多的“魔法”，除非有一个很好的理由，否则魔法不应该发生。只有当它创造了一个在其他方面无法实现的巨大便利时，魔法才是值得使用的，而且它的实现方式并没有使试图学习如何使用该特性的开发人员感到困惑。
框架应在所有级别上保持一致。一致性适用于从低级（使用的Python编码风格）到高级（使用django的“体验”）的所有方面。
字段不应仅基于字段名假定某些行为。这需要对系统有太多的了解，并且容易出错。相反，行为应该基于关键字参数，在某些情况下，还应该基于字段的类型。
模型应该封装“对象”的每个方面，遵循马丁·福勒的 Active Record 设计模式。
这就是为什么模型所表示的数据和有关它的信息（它的人类可读的名称、诸如默认排序等选项）都在模型类中定义的原因；理解给定模型所需的所有信息都应该存储起来。 in 模型。
数据库API的核心目标是：
它应该尽可能少地执行SQL语句，并且应该在内部优化语句。
这就是开发人员需要调用 save() 明确地说，而不是框架在幕后默默地保存东西。
这也是为什么 select_related() QuerySet 方法存在。对于选择“每个相关对象”的常见情况，它是可选的性能增强程序。
数据库API应该允许尽可能少的语法使用丰富、表达性的语句。它不应该依赖于导入其他模块或帮助器对象。
必要时，应在后台自动执行联接。
每个对象都应该能够访问系统范围内的每个相关对象。这种访问应该双向工作。
数据库API应该意识到它是一个快捷方式，但不一定是一个终点。框架应该使编写自定义SQL——整个语句，或者只是自定义 WHERE 子句作为API调用的自定义参数。
django应用程序中的URL不应耦合到底层的python代码。将URL绑定到python函数名是一件很糟糕的事情。
沿着这些线，DjangoURL系统应该允许同一个应用程序的URL在不同的上下文中是不同的。例如，一个站点可以在 /stories/ ，而另一个可以使用 /news/ .
URL应该尽可能灵活。应该允许任何可能的URL设计。
框架应该使开发人员设计漂亮的URL比设计丑陋的URL更容易（甚至更容易）。
应避免网页URL中的文件扩展名。
URL中的vignette样式的逗号应该受到严厉的惩罚。
从技术上讲， foo.com/bar 和 foo.com/bar/ 是两个不同的URL，搜索引擎机器人(以及一些网络流量分析工具)会将它们视为单独的页面。Django应该努力“标准化”URL，这样搜索引擎机器人就不会被搞糊涂了。
这就是 APPEND_SLASH 设置。
我们将模板系统看作是一个控制表示和表示相关逻辑的工具——就是这样。模板系统不应该支持超出这个基本目标的功能。
大多数动态网站都使用一些常见的网站范围设计——常见的页眉、页脚、导航栏等。Django模板系统应使这些元素易于存储在单个位置，从而消除重复代码。
这就是背后的原理 template inheritance .
模板系统不应该设计成只输出HTML。它应该同样擅长生成其他基于文本的格式，或者只生成纯文本。
使用XML引擎解析模板在编辑模板时引入了一个全新的人为错误世界——并且在模板处理中产生了不可接受的开销。
模板系统的设计不应该使模板在所见即所得编辑器（如Dreamweaver）中显示得很好。这是一个非常严重的限制，不允许语法像现在这样好。Django希望模板作者能够轻松地直接编辑HTML。
模板系统不应该用空白来做神奇的事情。如果一个模板包含空白，系统应该像对待文本一样对待空白——只显示它。应显示模板标记中没有的任何空白。
目的不是发明一种编程语言。目标是提供足够的编程风格的功能，例如分支和循环，这对于做出与表示相关的决策是必不可少的。这个 Django Template Language (DTL) 旨在避免高级逻辑。
Django模板系统认识到模板通常由 设计师 不是 程序员 ，因此不应假定具有Python知识。
现成的模板系统应该禁止包含恶意代码，例如删除数据库记录的命令。
这也是模板系统不允许任意Python代码的另一个原因。
模板系统应该认识到高级模板作者可能希望扩展其技术。
这是定制模板标记和过滤器背后的理念。
编写视图应该和编写Python函数一样简单。当函数执行时，开发人员不必实例化类。
视图应该可以访问请求对象——一个存储当前请求元数据的对象。对象应该直接传递给视图函数，而不是必须从全局变量访问请求数据的视图函数。这使得通过传递“假”请求对象来测试视图变得轻松、干净和容易。
视图不应该关心开发人员使用哪个模板系统，甚至不应该关心是否使用模板系统。
get和post是不同的；开发人员应该明确地使用其中一个。框架应该使区分get和post数据变得容易。
Django的核心目标 cache framework 是：
缓存应该尽可能快。因此，围绕缓存后端的所有框架代码都应该保持在绝对最小值，特别是对于 get() 操作。
缓存API应该在不同的缓存后端提供一致的接口。
缓存API应该可以根据开发人员的需要在应用程序级别进行扩展（例如，请参见 缓存密钥转换 ）
12月 18, 2023