首页 > temp > 简明python教程 >
-
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)。