本文解释Django的开发人员在创建框架中使用的一些基本哲学。 它的目标是解释过去和指导未来。
Django栈的基本目标是松耦合和紧密内聚。 框架的各个层不应该“知道”彼此，除非绝对必要。
例如，模板系统对Web请求一无所知，数据库层对数据显示一无所知，并且视图系统不关心程序员使用哪个模板系统。
尽管Django为了方便起见提供了一个完整的堆栈，但是堆栈的各个部分尽可能独立于另一个堆栈。
字段不应该仅仅基于字段的名称来承担某些行为。 这需要太多的系统知识，并且容易出错。 相反，行为应该基于关键字参数，在某些情况下，基于字段的类型。
模型应该根据Martin Fowler的Active Record设计模式封装“对象”的每个方面。
这就是为什么由模型表示的数据和关于它的信息（它的人类可读的名称，诸如默认排序等选项） 在模型类中定义；理解给定模型所需的所有信息应存储在中模型中。
数据库API的核心目标是：
它应该尽可能少地执行SQL语句，并且它应该在内部优化语句。
这就是为什么开发人员需要显式调用save()，而不是静默地保存场景。
这也是为什么QuerySet select_related()方法存在的原因。 这是一个可选的性能助推器，用于选择“每个相关对象”的常见情况。
数据库API应该尽可能少的语法允许丰富的表达性语句。 它不应依赖于导入其他模块或辅助对象。
在必要时，应在幕后自动执行连接。
每个对象应该能够访问每个相关对象，系统范围。 此访问应该两种方式工作。
数据库API应该意识到它是一个快捷方式，但不一定是一个端到端的。 框架应该使编写自定义SQL - 整个语句，或只是自定义WHERE子句作为自定义参数到API调用变得容易。
Django应用程序中的网址不应与底层Python代码相关联。 将URL绑定到Python函数名称是一个坏和丑陋的事情。
沿着这些线，Django URL系统应该允许同一个应用程序的URL在不同的上下文中是不同的。 例如，一个站点可以在/news/上放置故事，而另一个站点可以使用/stories/。
网址应尽可能灵活。 应该允许任何可想到的URL设计。
技术上，foo.com/bar/和foo.com/bar是两个不同的网址，搜索引擎机器人（和一些网络流量分析工具）会对待他们作为单独的页面。 Django应该努力“规范化”URL，以便搜索引擎机器人不会感到困惑。
这是APPEND_SLASH设置背后的原因。
模板系统不应设计为只输出HTML。 它应该同样好的生成其他基于文本的格式，或纯文本。
使用XML引擎解析模板在编辑模板时引入了一个全新的人为错误，并且在模板处理中产生了不可接受的开销水平。
不应将模板系统设计为使模板必须在所见即所得编辑器（如Dreamweaver）中很好地显示。 这太严格了，并且不允许语法像它那么好。 Django希望模板作者可以直接编辑HTML。
模板系统不应该用空格来做任何事情。 如果一个模板包含空格，系统应该在处理文本时对待空格 - 只显示它。
目标不是发明一种编程语言。 目标是提供足够的编程类型的功能，如分支和循环，这对于做演示相关的决定是必不可少的。 Django模板语言（DTL）旨在避免高级逻辑。
Django模板系统认为模板最常由设计师而不是程序员写，因此不应假定Python知识。
2017年9月6日