Django 读作姜戈，第一个 D 不发音，与电影《被解救的姜戈》的姜戈除了读音一样，没有其他半毛钱关系。Django 是一个优秀的 Web 框架，用 Python 编写，是非常流行的全栈框架。
Django 的诞生基于非常朴素的需求，2003 年的秋天，两位主创人员Adrian Holovaty和Simon Willison）为了快速开发，抛弃了 PHP 转而使用 Python，来满足新闻网站的快速迭代开发需求，在开发的过程中他们发现很多共性的代码可以提取出来复用，从而减少工作量，提高效率，慢慢的就开发出一个可以填空的 Web 框架，这个框架被越来越多的人使用，于是在 2005 年的夏天，Django 源码开放，一度成为非常流程的框架，有着数以万计的用户和贡献者，在世界广泛传播的完善开源项目。
Django 是完美主义者的开发框架，和 Python 一样有着自己的设计哲学：
一、总体架构方面：
1、松耦合
Django 的基本目标是松耦合和高内聚。除非绝对必要，否则框架的各个层次都不应“相互了解”。例如，模板系统对Web请求一无所知，数据库层对数据显示层一无所知，而视图系统不在乎程序员使用哪个模板系统。
2、更少的代码
Django app 应使用尽可能少的代码，充分使用 Python 语言的动态能力，比如自省功能，自省就是让程序自我反省，比如让程序自己告诉我们它是谁，它在哪里，它要做什么，这些可以借助很多 Python 内置函数来实现：如 help()，dir()，type()，id()，hasattr()等。
3、快速的迭代开发
Web 开发的节奏越来越快，开发也必须越来越高效，Django 设计之初就是为了适应快节奏的开发速度。
4、不要做重复劳动
每一个不同的模块都应该位于一个地方，且只有这一个地方，代码不要冗余，要规范化，很多 App 在 Django 这里都是可以直接复用的，而且很容易的添加和删除（通过配置 INSTALLED_APPS）。
5、显式胜于隐式
这是 Python 中的核心原则 PEP 20，这意味着 Django 不应做太多“魔术”功能“魔术”功能，除非有充分的理由。仅当“魔术”功能创造了其他方式无法实现的巨大便利时，才值得使用，而且它的实现方式也不会使试图学习该功能的开发人员感到困惑。
6、一致性
Django框架应在所有级别保持风格一致，如从底层级的 Python 代码，到高层的继承及调用，每一个 Django 的代源码，看起来都非常具有 Django 的风格，这非常的优雅，易于阅读和理解，降低学习成本。
二、模型(Models)设计方面：
1、显式胜于隐式
字段不应仅基于字段名称承担某些行为。这需要太多的系统知识，并且容易出错。相反，行为应基于关键字参数，并且在某些情况下，应基于字段的类型。
2、包含所有相关联的数据项
Models应遵循Martin Fowler的Active Record设计模式[https://www.martinfowler.com/eaaCatalog/activeRecord.html]来封装“对象”的各个方面。这就是为什么在模型类中同时定义了模型所代表的数据和有关该模型的信息（其可读名称，默认排序等选项）的原因；了解给定模型所需的所有信息都应存储在模型中。
三、数据库层面：
1、SQL效率提升
应该尽可能少地执行 SQL 语句，并且在内部优化语句。这就是开发人员需要 save() 显式调用的原因，而不是框架无声地将事情隐藏在后台。这也是 select_related() QuerySet 方法存在的原因，对于常见的查询相关对象的情形，它是可选的性能提升器。
2、简洁强大的语法
数据库 API 应该允许使用尽可能少的语法表达性语句。它不应依赖于导入其他模块或辅助对象。如有必要，应在后台自动加入关联。每个对象都应该能够访问系统范围内的每个相关对象。这种访问方式应同时起作用。
3、可以执行原始 SQL
数据库 API 应该意识到这是一个捷径，但并不是所有问题的终结。框架应使编写自定义 SQL（整个语句）或仅将自定义WHERE子句变得更容易实现。
四、网址设置层面：
1、松耦合
Django 应用中的 URL 不应与基础 Python 代码耦合。将 URL 绑定到 Python 函数名称是一件不好的事。遵循这些原则，Django URL 系统应该允许同一应用程序的 URL 在不同的上下文中有所不同。例如，一个站点可能会在放置故事 /stories/，而另一个站点可能 会使用/news/。
2、灵活性与优雅
网址应尽可能灵活。任何可能的 URL 设计都应允许。
应该使开发人员设计出美观的 URL 比设计出丑陋的 URL 变得一样容易甚至更容易。
网页 URL 中的文件扩展名应避免。URL中的小插图样式逗号应受到严惩。
3、标准化
从技术上讲，foo.com/bar 和 foo.com/bar/ 是两个不同的网址，搜索引擎机器人（和某些Web流量分析工具）将它们视为单独的页面。Django应该努力“标准化” URL，以免搜索引擎机器人感到困惑。
这就是 Django 会自动在网址结尾加 ‘/’（ APPEND_SLASH 默认设置为 True） 的原因。
五、模板系统方面：
1、表示法与逻辑分开
我们将模板系统视为控制演示和与演示相关逻辑的工具，仅此而已。模板系统不应支持超出此基本目标的功能。
2、阻止冗余
大多数动态网站使用某种通用的站点范围设计-通用的页眉，页脚，导航栏等。Django模板系统应使将这些元素轻松存储在单个位置中，从而消除重复的代码。这就是模板继承的原理。
3、与 HTML 分离
模板系统不应设计为仅输出 HTML。同样，它应该能够很好地生成其他基于文本的格式，或者仅仅是纯文本。
4、XML不应该用于模板语言
使用XML引擎解析模板会在编辑模板时引入一个全新的人为错误世界，并在模板处理中产生不可接受的开销。
5、可以轻松编辑
模板系统的设计不应使模板必须在所见即所得的编辑器（例如Dreamweaver）中很好地显示。这样的限制太严酷了，不会让语法看起来像现在一样好。Django 希望模板作者可以轻松地直接编辑HTML。
6、明显地对待空白
模板系统不应使用空格执行魔术操作。如果模板包含空白，则系统应在处理文本时将其视为空白–仅显示它。任何空格，只要模板标记中没有的，都应该显示它。
7、不要发明一种编程语言
目的不是发明一种编程语言。目的是提供足够的编程式功能，例如分支和循环，这对于做出与演示相关的决定至关重要。在 Django 的模板语言（DTL）是为了避免高级逻辑。
Django 模板系统认识到模板通常是由设计人员而不是程序员编写的，因此不应假定具备 Python 知识。
8、安全性
开箱即用的模板系统应禁止包含恶意代码，例如删除数据库记录的命令。这是模板系统不允许任意Python代码的另一个原因。
9、扩展
模板系统应认识到高级模板作者可能希望扩展其技术。这是自定义模板标签和过滤器背后的理念。
六、视图方面：
1、简单
编写视图应该和编写 Python 函数一样简单。当函数可以使用时，开发人员不必实例化一个类。
2、使用请求对象
视图可以访问请求对象：一个存储有关当前请求的元数据的对象。该对象应直接传递给视图函数，而不是视图函数必须从全局变量访问请求数据。通过传递一个构造的请求对象，视图可以可以非常轻巧，干净且易于测试。
3、松耦合
视图不应该在乎开发人员使用哪种模板系统，甚至也不必在乎模板系统是否被使用。这一点使得 django 可以轻松地和 Vue 配合使用。
4、区分 GET 和 POST
GET 和 POST 是不同的；开发人员应明确使用其中之一。框架应易于区分 GET 和 POST 数据。
七、缓存框架方面
Django 缓存框架的核心目标是：
1、更少的代码
高速缓存应尽可能快。因此，围绕缓存后端的所有框架代码都应保持绝对最小，尤其是对于 get() 操作而言。
2、一致性
缓存 API 应该在不同的缓存后端之间提供一致的接口。
3、扩展
缓存 API 应根据开发人员的需求在应用程序级别进行扩展（请参阅缓存密钥转换[https://docs.djangoproject.com/en/3.1/topics/cache/#cache-key-transformation]）。
参考文档：https://docs.djangoproject.com/en/3.1/misc/design-philosophies/
PS：后面如果接一些 Python 相关的推广课程，大家按需选择即可，同时会在文末设置抽奖活动，不赚钱，交个朋友，感谢大家的支持。
