简介
Django 是一个完备的基于Python的web开发的框架。Django框架具备快速、高效、简洁、实用等特点。
这篇文章主要介绍了Django项目在开发中的一些指导思想。
Django
[color="#0066cc"]设计
思路
这个文档解释了一些在Django开发人员在开发Django项目中基本的思路。无论是以前还是未来，这些基本的思路将会贯穿Django开发的整个过程。
概述
松耦合
Django的一个基本目标是
[color="#0066cc"]松耦合，强内聚
。在框架中不同层（layer）相互隔离，不应该有所渗透，除非万不得已。比如，模板（template）系统不会包含任何web 请求的对象，数据库层面不会关心数据是如何显示，而视图也不关心数据用模板来呈现的细节。
尽管Django提供了一整套从数据库到页面的快速开发框架，但在各个层级都尽可能的保持独立，相互隔离。
少写代码
Django应用开发应该能尽可能的减少代码量；精简模板。Django应当充分发挥Python语言的动态特性，例如自省。
快速开发
21世纪web框架最重要的是什么？是能够多快好省得完成繁复的web应用开发。Django应该能使显著提升web开发的速度。
不要重复自己（
[color="#0066cc"]DRY
）
每一个不同的概念或者一份数据都应该只在一个地方保有一份。冗余是需要避免的。标准化的数据是好的。
框架在合理的范围内应当尽可能的细化，以保证更多的可复用性。
显示说明比隐含意义好
这也是
[color="#800080"]Python的核心原则
，他意味着Django不应该有太多晦涩难懂的“魔术代码”。除非有充分的理由可以允许这些不易理解的代码存在。比如，某些“魔术代码”能带来很多的方便而且难以替代，同时这些代码所实现的流程容易为开发者所理解。
一致性
框架应当在各个层面保持一致性。从低级别的比如Python编码格式的一致性，到高级别的使用Django规则的一致性。
模型（对象模型）
显示说明比隐含意义好
不应该仅仅依赖字段的命名来预示其可能的行为，这样需要你对整个系统十分聊天，而且还容易猜错。相反，操作应该依赖关键的参数，在某些情况下需要依靠字段的类型来表示。
模型中应包含相关的各种业务逻辑
根据老马（Martin Fowler）的
[color="#0066cc"]Active Record
设计模式，模型应该封装对象的每个方面。所以在模型类中会定义模型数据以及数据相关的描述信息（方便记忆的别名，可选的默认排序字段等）
数据库API
数据库API的主要目的如下：
提高sql的效率
它应该尽可能少的执行SQL语句，同时尽可能的优化SQL语句的执行。
这就是为什么开发人员需要显示的调用save()方法，而不是由框架在后台自动的保存数据。
这也是为什么会有select_related() QuerySet方法存在的原因。它可以优化查询【多对多关系（every related object）？？】的性能。
简洁明了的语法
数据库API应该用尽可能短的语法来表达丰富的表达语句。它不应该再引用其他的模块或者帮助类。
在需要的时候，表的连接（join）会在后台被自动执行。
在同一体系内，相互关联的对象应该能够被双向关联引用。
当需要的时候可以选择简单的直接写SQL文
数据库API应当只是方便进行数据库操作的封装，而不需要封装所有的数据库操作。框架应该提供可以直接执行SQL文的操作，SQL文可以是一个完整的语句，也可以只是拼装where以后的条件语句。
URL的
[color="#0066cc"]设计
[color="#0066cc"]
松耦合
URLs在Django中不会直接与Python的代码进行关联映射。用Python的方法名来定义URL不是一个好主意。
在松耦合的指导下，Django的URL映射可以将相同的应用服务映射到不同的URL路径上。比如一个网站可能将sotries服务配置到/stories/,而另一个网站则可以把它配置到/news/路径下。
可以无限扩展
URLs应该可以很灵活的进行映射。能想出的映射方式都应该被支持。
鼓励URL的最佳实践
框架应当提供对良好形势的URL的支持。扩展名的URL应该避免，在URL中用逗号也应当避免。
确定的URLs
技术上讲foo.com/bar 和 foo.com/bar/ 是两个不同的URLs，搜索引擎的爬出（或者其他网络流量分析工具）会把它们看成2个不同的页面。Django应当避免这样的区分。
这就是为什么需要自动加/(APPEND_SLASH)设置的由来。
模板系统
将业务逻辑与表现分离
我们仅仅利用模板作为数据展现控制已经数据展现相关的逻辑的工具，模板系统不应当提供超出此基本操作的其他方法。
如果我们希望在模板中包含所有的业务逻辑那不如就去用PHP.(een there, done that, wised up.)
避免冗余
在动态网站的
[color="#0066cc"]设计
中都会有一些通用的元素，比如页头，页脚，导航栏等等。在Django的模板中可以把这些通用元素提出单独保存，以避免在很多页面上重复出现。
这就是模板继承(
[color="#0066cc"]template inheritance
)的理论指导。
与HTML脱离
模板系统不只是用来生产HTML代码的，它同样可以生成其他文本形式，或者纯文本。
不应当使用XML作为模板语言
使用XML作为模板使得模板文件难以编辑，容易出错；而且在转换模板时效率也很差。
模板的编写者应具有一定的HTML
[color="#0066cc"]设计
能力
模板系统不应当是使用所见即所得的编辑器（例如Dreamweaver）制作出来。那样的模板中会包含太多的附加代码。Django希望模板开发人员可以手工编写模板文件。
保留模板中的空白字符
模板系统应该统一处理模板中的空白。如果一个模板中包含空白字符，则应该保留这些空白。任何不在模板标签中的空白都应该被保留。
不要在模板创造一门语言
模板系统中不允许以下行为：
.给变量赋值
.额外的业务逻辑
模板的目的不是发明一个新的编程语言，而是为页面显示提供循环，分支判断等简单的编程支持就可以了。
Django模板系统通常是有页面
[color="#0066cc"]设计
来编写，而不是程序员，所以编写模板中不需要了解Python语言的相关知识。
安全保障
在模板系统中应当避免包含恶意操纵代码，比如删除数据库记录的方法等。
这也是为什么不能在模板中使用Python语句的一个原因。
可扩展
模板系统应该可以让用户在现有模板的基础上进行扩展。
这也是自定义模板与过滤器的理论指导。
视图
简单
写一个视图应当想写一个Python的方法一样简单。当一个方法能完成的工作就不需要实例化一个类来完成。
使用请求(request)对象
视图应当可以读取请求对象：一个包含当前请求元数据的对象。这个对象应该作为参数直接传入到视图里的方法中，而不是作为一个全局变量提供给视图。这样的实现很轻巧，简单，很方便模拟请求对象来测试视图中的方法。
松耦合
视图并不关心使用什么样的模板系统，甚至不知道是否在使用模板系统。
区分GET和POST方法
GET和POST方法是不同的，开发人员应该明确的选择用哪一个。框架应该能够很容易的区分GET和POST的数据。
