而对于真实开发中的python web程序来说，一般会分为两部分：服务器程序和应用程序。服务器程序负责对socket服务器进行封装，并在请求到来时，对请求的各种数据进行整理。应用程序则负责具体的逻辑处理。为了方便应用程序的开发，就出现了众多的Web框架，例如：Django、Flask、web.py 等。不同的框架有不同的开发方式，但是无论如何，开发出的应用程序都要和服务器程序配合，才能为用户提供服务。这样，服务器程序就需要为不同的框架提供不同的支持。这样混乱的局面无论对于服务器还是框架，都是不好的。对服务器来说，需要支持各种不同框架，对框架来说，只有支持它的服务器才能被开发出的应用使用。这时候，标准化就变得尤为重要。我们可以设立一个标准，只要服务器程序支持这个标准，框架也支持这个标准，那么他们就可以配合使用。一旦标准确定，双方各自实现。这样，服务器可以支持更多支持标准的框架，框架也可以使用更多支持标准的服务器。
WSGI（Web Server Gateway Interface）是一种规范，它定义了使用python编写的web app与web server之间接口格式，实现web app与web server间的解耦。
python标准库提供的独立WSGI服务器称为wsgiref。
MVC是众所周知的模式，即：将应用程序分解成三个组成部分:model(模型),view(视图),和 controller(控制 器)。其中：
M 管理应用程序的状态（通常存储到数据库中），并约束改变状态的行为（或者叫做“业务规则”）。
C 接受外部用户的操作，根据操作访问模型获取数据，并调用“视图”显示这些数据。控制器是将“模型”和“视图”隔离，并成为二者之间的联系纽带。
V 负责把数据格式化后呈现给用户。
在《Agile Web Development with Rails》中有这样一张图对MVC模式进行了很好的解释：
Django也是一个MVC框架。但是在Django中，控制器接受用户输入的部分由框架自行处理，所以 Django 里更关注的是模型（Model）、模板(Template)和视图（Views），称为 MTV模式：
M 代表模型（Model），即数据存取层。 该层处理与数据相关的所有事务： 如何存取、如何验证有效性、包含哪些行为以及数据之间的关系等。
T 代表模板(Template)，即表现层。 该层处理与表现相关的决定： 如何在页面或其他类型文档中进行显示。
V 代表视图（View），即业务逻辑层。 该层包含存取模型及调取恰当模板的相关逻辑。 你可以把它看作模型与模板之间的桥梁。
需要注意的是，不能简单的把 Django 视图认为是MVC控制器，把 Django 模板认为MVC视图。
区别在于：
Django 视图 不处理用户输入，而仅仅决定要展现哪些数据给用户；
Django 模板 仅仅决定如何展现Django视图指定的数据。
或者说, Django将MVC中的视图进一步分解为 Django视图 和 Django模板两个部分，分别决定 “展现哪些数据” 和 “如何展现”，使得Django的模板可以根据需要随时替换，而不仅仅限制于内置的模板。
至于MVC控制器部分，由Django框架的URLconf来实现。URLconf设计非常巧妙，其机制是使用正则表达式匹配URL，然后调用合适的Python函数。虽然一开始有些不习惯，但是你很快就会喜欢上它，因为URLconf对于URL的规则没有任何限制，你完全可以设计成任意的URL风格，不管是传统的，RESTful的，或者是另类的。
T 代表模板 (Template)：负责如何把页面展示给用户(html)。
V 代表视图（View）：负责业务逻辑，并在适当时候调用Model和Template。
2，Django在URLconf里查找对应的视图(View)函数来处理http请求
3，视图函数调用相应的数据模型来存取数据、调用相应的模板向用户展示页面
4，视图函数处理结束后返回一个http的响应给Web服务器
5，Web服务器将响应发送给客户端
比如，开发者更改一个应用程序中的 URL 而不用影响到这个程序底层的实现。设计师可以改变 HTML页面的样式而不用接触Python代码。
数据库管理员可以重新命名数据表并且只需更改模型，无需从一大堆文件中进行查找和替换。
