DJANGO 框架架构简析

摘要

随着互联网的发展，越来越多的Web开发框架应运而生。Django就是其中一款既能节约开发时间又能让开发充满乐趣的流行开发框架。本文主要从架构方面简要介绍Django Web开发框架，通过分析其架构来探索为什么使用Django能够花费不多的时间构建和维护质量上乘的Web应用。

Web框架介绍

在互联网诞生之际，人们是通过编写标准的CGI程序来开发Web应用的，此时程序员需要处理所有的操作以完成一个静态页面的展示，若是展示动态页面，程序员的工作将变得非常负责而且容易出错，这是他将面临许多问题，如：

1.当多个动态页面需要同时连接数据库时，将会发生什么？

2.一个开发人员真的需要去关注如何输出Content-Type以及完成所有操作后去关闭数据库么？尤其是明白此类问题只会降低开发人员的工作效率，增加犯错误的几率。

3.如果这样的代码被重用到一个复合的环境中会发生什么？每个页面都分别对应的数据库和密码吗？

4、如果一个Web设计师，完全没有某门新语言的开发经验，但是又需要使用新语言重新设计页面的话，又将发生什么呢？

以上正是Web框架致力于解决的问题。Web框架为应用程序提供了一套程序框架，这样你可以专注于编写清晰、易维护的代码，而无需从头做起。针对问题1，一个Web开发框架会把连接数据库的代码都统一重新组织到一个公共函数里以减少代码量。针对问题2，框架会帮助完成初始化和释放资源相关的工作。针对问题3，Web开发框架一般都会有环境相关的配置文件以增强程序的可移植性。对于问题4，理想的情况是将业务逻辑与实际数据操作分开，这样设计师的重新设计可以不对实际生产造成太大的影响。

一般情况下，Web开发框架的诞生历程是这样的：

1.从头开始编写网络应用程序。

2.从头编写另一个网络应用程序。

3.从第一步中总结（找出其中通用的代码），并运用在第二步中。

4.重构代码使得能在第2个程序中使用第1个程序中的通用代码。

5.重复2-4步骤若干次。

6.意识到发明了一个框架。

Django框架简介

Django是从真实世界的应用中成长起来的，它是由堪萨斯州Lawrence城中的一个网络开发小组编写的。它诞生于2003年秋天，那时Lawrence Journal-World报纸的程序员Adrian Holovaty和Simon Willison开始用Python来编写程序。当时他们的World Online 小组制作并维护当地的几个新闻站点，并在以新闻界特有的快节奏开发环境中逐渐发展.。这些站点包括有LJWorld.com、Lawrence.com和KUsports.com，用户要求增加的特征或整个程序都能在计划时间内快速的被建立，这些时间通常只有几天或几个小时。因此为了需要，Adrian和Simon开发了一种节省时间的网络程序开发框架，这是在截止时间前能完成程序的唯一途径。

2005年的夏天，当这个框架开发完成时，它已经用来制作了很多个World Online的站点。当时World Online小组中的Jacob Kaplan-Moss决定把这个框架发布为一个开源软件。他们在2005年的7月发布并取名为Django，来源于一个著名的爵士乐吉他演奏家Django Reinhardt。

Django架构分析

Django架构总览

图1Django架构总览图

从图中可以看去，Django使用的是非常清晰的分层结构，最上层是基本的网络通信处理，接下来是应用层，与传统的MVC模式稍有不同，采用的是独有的MTV模式，即Model，View，Template。

在传统的MVC模式中，M，Model层，是数据访问层，处理与数据相关的操作，如如何存取、如何确认有效性，哪些行为用到哪些数据等等，用于处理业务逻辑；V，View层，决定系统显示什么以及如何显示内容，用于与用户进行交互；C，Controller层，是Model 层与View层沟通的桥梁，通过View层接收的输入选择相应Model进行处理并再使用合理的View展示给用户。

而在Django的MTV模式中，M依旧代表Model层，也是与数据处理相关的部分，与MVC模式相同；T，Template层，负责展示，决定数据如何显示；而V，虽然还是叫做View 层，但由于展示相关的部分已有Template层完成，所以这里的View层主要负责业务逻辑，决定展示的时候需要调用的Template，也就是说在Django框架中的VC合起来相当于MVC 中的V。至于MVC模式中的C则已经集成到框架本身，由框架自身完成相关工作，这比传统的MVC模式更进一步减少了程序员的工作，所以开发效率有了进一步的提高。

接下来是颇具特色的对象关系映射和模版引擎。对象关系映射（ORM）是指以Python 类形式定义你的数据模型。ORM将模型与关系数据库连接起来，你将得到一个非常容易使用的数据库API，同时你也可以在Django中使用原始的SQL语句。这种设计即便于开发也便于阅读和理解。在移植和维护代码时会减少不少工作，更加快捷和有效。模版引擎也是很有特色的一个功能。首先来介绍一下模版，模版是一个纯文本文件，或是一个用Django 模板语言标记过的普通的Python字符串，一个模板可以包含区块标签和变量。模版引擎就是处理模版相关的操作的。有了模版引擎，不仅可以使代码显得简介，同时代码和逻辑分离是程序员协同工作时不会互相干涉，造成混乱。

最底层是存放数据和文件的数据库系统和文件系统。

Django框架实现

1、Django框架目录结构

图2Django框架目录结构

Conf，主要有两个作用：1)处理全局配置,比如数据库、加载的应用、MiddleWare等2)处理urls配置,就是url与View的映射关系。

Contrib，由Django的开发者贡献的功能模块，不过既然都已经随版本发布，就表示是官方的。

Core，Django的核心处理库，包括url分析、处理请求、缓存等，其中处理请求是核心了，比如处理fastcgi就是由wsgi.py处理。

Db，顾名思义，处理与数据库相关的，就是ORM。

Dispatch，其实这不是Django原创，是pydispatch库，主要处理消费者-工作者模式。

forms&&newforms&&oldforms，处理html的表单，不用多介绍。

Middleware，中间件，就是处理HTTP的request和response的，类似插件。比如默认的common中间件的一个功能：当一个页面没有找对对应的pattern时，会自定加上‘/’重新处理。比如访问/blog时，而定义的pattern是‘^blog/$’，所以找不到对应的pattern，会自动再用/blog/查找，当然前提是APPEND_SLASH=True。

Template，Django的模板。

Templatetags，处理Application的tag的wrapper，就是将INSTALLED_APPS中所有的Templatetags目录添加到Django.Templatetags目录中，则当使用{{load blog}}记载tag 时，就可以使用import Django.Templatetags.blog方式加载了。不过这有一个问题，如果其他Application目录中也有blog.py，这会加载第一个出现blog.py的tag。其实在Django中，有许多需要处理重名的地方，比如Template，需要格外小心，这个后续在介绍。

Utils，公共库，很多公用的类都在放在这里。

Views，最基本的View方法。

2、Django框架程序组成

Project，一个完整的Web服务，一般由多个模块组成。

Application，可以理解为模块，比如用户管理、博客管理等，包含了数据的组成和数据的显示，Applicaiton都需要在"project/settings.py"中INSTALLED_APPS的定义。

Middleware，插件，处理request和response的，Middleware都需要在"project/settings.py"中MIDDLEWARE_CLASSES的定义。

Loader，模板加载器,其实就是为了读取Template文件的类，默认的有通过文件系统加载和在"Application/Templates"目录中加载，Loader都需要在"project/settings.py"中Template_LOADERS的定义。

3、Django框架处理流程

以request->response为例：

1>加载配置

Django的配置都在"Project/settings.py"中定义，可以是Django的配置，也可以是自定义的配置，并且都通过Django.conf.settings访问，非常方便。

2>启动最核心动作的是通过Django.core.management.commands.runfcgi的Command来启动，它运行Django.core.servers.fastcgi中的runfastcgi，runfastcgi使用了flup的WSGIServer来启动fastcgi。而WSGIServer中携带了Django.core.handlers.wsgi的WSGIHandler类的一个实例，通过WSGIHandler来处理由Web服务器(比如Apache，Lighttpd等)传过来的请求，此时才是真正进入Django的世界。

3>处理Request

当有HTTP请求来时，WSGIHandler就开始工作了，它从BaseHandler继承而来。WSGIHandler为每个请求创建一个WSGIRequest实例，而WSGIRequest是从http.HttpRequest继承而来。接下来就开始创建Response了。

4>创建Response

BaseHandler的get_response方法就是根据request创建response，而具体生成response 的动作就是执行urls.py中对应的View函数了，这也是Django可以处理“友好URL”的关键步骤，每个这样的函数都要返回一个Response实例。此时一般的做法是通过loader加载Template并生成页面内容，其中重要的就是通过ORM技术从数据库中取出数据，并渲染到Template中，从而生成具体的页面了。

5>处理Response

Django返回Response给flup，flup就取出Response的内容返回给Web服务器，由后者返回给浏览器。

总之，Django在fastcgi中主要做了两件事：处理Request和创建Response，而它们对应的核心就是“urls分析”、“模板技术”和“ORM技术”，整个处理过程如下图所示：

图3Django处理流程