Django的设计理念和哲学

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）。

更多内容请访问: https://www.liujiangblog.com

更多视频教程请访问: https://www.liujiangblog.com/video/