Django作为一个庞大的、自带电池的、整体Web开发解决方案框架，源代码多、子系统多、工具多。要将如此多的内容集成到一起，必然需要一个指导性的设计理念和哲学思维。这样才不至于显得东拼西凑、杂乱无章、接口混乱，而是整体一致、思路清晰、逻辑合理。既方便了源码开发，也方便了应用开发。
下面就介绍一下Django的设计理念和哲学思维，这其中有一些是Django源代码中正在遵循的，一些是使用者开发项目过程中需要遵循的：
系统性原则
松耦合
Django 追求各子系统（层）的低耦合和高内聚。各层之间保持代码独立、功能独立、尽量没有交联。
例如，模板层不需要知道用户的 Web 请求具体情况，模型层不需要了解模板层是如何展示数据的，视图层也不关心程序员所使用的模板系统到底是哪种和怎么使用的。通俗地说，模型层只关心数据的CRUD，视图层只负责业务逻辑的实现，模板层只管前端页面的渲染和展示。这三个核心层之间只有数据的传递，没有代码的交互，各自相对独立。
更少的代码
Django 建议每个APP的代码应该尽可能地精简，应该充分利用 Python 的动态能力，比如自省机制（introspection）。
快速开发
Django诞生于一个新闻编辑社，其应用环境要求快速开发和迅速迭代，所以在设计之初就追求以更快的速度实现需求的处理，你只需要编写一些新代码，或者修改一些局部代码就可以实现新的站点。
不要重复地造轮子 (DRY)
除非有特殊需求，所有官方或者生态圈内已经提供的库、工具、插件和功能，请直接拿来使用，不要自己开发。
明确优于隐式
这条原则的根本意思是：不要玩花招、炫技巧，尽可能用更普通、更明确、更直观的语法，不要使用那些晦涩难懂的语法。将你的代码写得更啰嗦、更直白、更清晰，多两行不怕，多点注释更好。
一致性
框架应在所有层级上保持一致。一致性适用于从低级（Python 的编码风格）到高级（使用 Django 的“经验”）的所有内容。
这条规则既有代码规范上的要求，也有开发习惯的要求，要在整个项目中保持统一的风格。代码如其人，程序员是个什么样的性子和思路，在代码里能看得清清楚楚。要保持人设的统一性，不要前面是狂野粗放的大汉，后面是裹脚布又臭又长，这样不好，让人以为代码是好多不同的人写的，没有一个统一的章法。
模型层相关
明确优于隐式
字段不应该仅仅根据字段的名称来假定某些行为。这需要对系统有太多了解，并且容易出现错误。相反，其行为应该基于关键字参数，并且在某些情况下，应该基于字段的类型。
白话说就是：不要通过字段的名称上来指定它的功能，而应该通过详细、明确地选择字段的类型，定义字段的参数来设计字段。
模型应当包含所有信息
模型中应该封装一个“对象”的各个方面，并遵循 Martin Fowler 的 Active Record 设计模式。
也就是说，对于一个模型，任何与之相关的元信息、方法、函数、属性，包括其人类可读的名称，默认排序等选项，这些所有用于理解该模型所需的信息，都应该存储在模型中，而不要将它们放到视图、URL或者模板中去实现。
ORM相关
提高SQL效率
应该尽可能少地执行SQL语句，并且应该在内部优化语句。
开发者需要显式地调用 save()，而不是由框架静默地在幕后保存数据。
API应该简洁并强大
ORM的API 应该允许用尽可能少的语法，来表达丰富、达意的语句。它不应该依赖于导入其他模块或辅助对象。
每一个对象都应该能够访问所有相关的对象，和系统范围，并且这种访问应该是双向的。
支持使用原生 SQL 语句
ORM的API 只是一个便捷的方法，但并不是最终的全部手段，框架必须支持使用原生SQL语句，这一点Django做到了。
URL 设计相关
松耦合
Django 应用中的 URL 不应该与底层 Python 代码耦合。将 URL 与 Python 函数名联系起来是一件很糟糕且丑陋的做法。
也就是说，APP中的视图到底干什么，和你的URL到底写成啥样没有关系，不能将URL和APP捆在一起绑死了。例如，一个网站可以在 /stories/ 中放置故事，而另一个网站则可以使用 /news/来放置故事，两种不同的URL其背后的APP是一样的，我虽然复用了APP，但我可以使用另外一套URL去映射它。
无限的灵活性
URL 应该尽可能灵活。任何可想到的 URL 设计都应该被允许。
URL应该优雅
设计漂亮的URL，而不是难看的 URL。
在 URL 中应避免出现文件后缀名。
在 URL 中不应使用 Vignette 式的逗号。
最后的斜杠
从技术上而言，foo.com/bar 和 foo.com/bar/ 是两条不同的 URL，搜索引擎爬虫（以及某些 Web 流量分析工具）会将其视为独立的两个页面。但是Django 会将其转为 "标准" 的 URL，让搜索引擎爬虫正确识别。详细参考 APPEND_SLASH 配置。
模板系统相关
逻辑分离的解决方案
我们将模板系统看作一个工具，用于控制表现方式和表示方式相关的逻辑。模板系统不应该支持超出这个基本目标的功能。
避免冗余
大多数动态网站会使用一些网站整体通用的设计，比如通用的页眉、页脚、导航栏等等。Django 模板系统遵循了这一点，可以很容易地将这些元素存储在一个地方，从而减少重复的代码。
从 HTML 中解耦
模板系统不应该被设计成只能输出 HTML。它应该同样擅长生成其他基于文本的格式，或者仅仅是纯文本。
XML不应被用于模板语言
使用 XML 引擎去解析模板会在编辑模板的过程中引入很多人为错误，并在模板处理中导致不可接受的开销。
不要指望模板系统能包打天下
Django 期望模板编写者有能力直接编辑 HTML 文本。
更加直接的处理空格
模板系统不应该用空白符来做神奇的事情。如果模板包含空白符，系统应该在处理文本时处理空格——只是显示它。任何不在模板标签中的空白符都应该显示出来。
不要发明一种编程语言
模板系统的目标不是发明一种编程语言。它的目标是提供足够的具有编程风格的功能，比如分支和循环，这对于做出表现相关的决策是至关重要的。Django 模板语言（DTL） 旨在避免高级逻辑。
Django 模板系统认为模板通常是由 设计师 编写的，而不是 程序员，因此不应该假设他了解 Python。
所以，我们在使用Django的模板系统时会发现，这只是一个具有一般编程功能的渲染工具，不要妄图把它当作一个功能强大、语法完整的编程语言来使用。
安全与保障
开箱即用的模板系统禁止包含恶意代码，例如删除数据库记录的代码。
这也是模板系统不允许有任意Python代码的另一个原因。
可扩展性
模板系统应该认识到, 高阶的模板作者可能想扩展它。
这是自定义的模板标签和过滤器背后的理念。
视图
尽量简洁
编写视图应该和编写 Python 函数一样简单。开发人员不应该在函数执行时实例化一个类。
使用请求对象
视图应该能够访问一个请求对象——一个储存关于当前请求的元数据的对象。对象应该直接传递给视图函数，而不是必须从全局变量访问请求数据的视图函数。这使得通过传入“假”请求对象来测试视图变得轻松、干净和容易。
根据这条理念，Django每个视图函数的第一个参数都是request，从这个request中，我们可以拿到所有用户请求相关的数据。
松耦合
视图不应该关心开发人员使用哪种模板——甚至根本不用模板系统。
GET 方法和 POST 方法的区别
GET 和 POST 是不同的；开发人员应该明确地使用其中一个或另一个。框架应该使得 GET 和 POST 数据很容易区分。
所以，在使用函数型视图的时候，应该明确地写明：if request.method=='GET':pass，而不要使用默认的函数执行顺序。
缓存框架相关
缓存框架 的核心目的是：
更少的代码
缓存应该尽可能快。因此，围绕缓存后端的所有框架代码都应该保持在绝对的最小值，特别是对于 get() 操作。
一致性
缓存 API 应该为不同的缓存后端提供一致的接口。
可扩展性
缓存 API 应该基于开发者的需求，在应用程序级别上是可扩展的（例如，参见 Cache key transformation）。
