MVC架构

wsgiref模块版web框架

• wsgiref模块其实就是将整个请求信息给封装了起来，就不需要你自己处理了，假如它将所有请求信息封装成了一个叫做request的对象，那么你直接request.path就能获取到用户这次请求的路径，request.method就能获取到本次用户请求的请求方式(get还是post)等，那这个模块用起来，我们再写web框架是不是就简单了好多啊。

• 对于真实开发中的python web程序来说，一般会分为两部分：服务器程序和应用程序。服务器程序负责对socket服务器进行封装，并在请求到来时，对请求的各种数据进行整理。应用程序则负责具体的逻辑处理。为了方便应用程序的开发，就出现了众多的Web框架，例如：Django、Flask、web.py 等。不同的框架有不同的开发方式，但是无论如何，开发出的应用程序都要和服务器程序配合，才能为用户提供服务。

• 服务器程序就需要为不同的框架提供不同的支持。这样混乱的局面无论对于服务器还是框架，都是不好的。对服务器来说，需要支持各种不同框架，对框架来说，只有支持它的服务器才能被开发出的应用使用。最简单的Web应用就是先把HTML用文件保存好，用一个现成的HTTP服务器软件，接收用户请求，从文件中读取HTML，返回。

• 我们不希望接触到TCP连接、HTTP原始请求和响应格式，所以，需要一个统一的接口协议来实现这样的服务器软件，让我们专心用Python编写Web业务。这时候，标准化就变得尤为重要。我们可以设立一个标准，只要服务器程序支持这个标准，框架也支持这个标准，那么他们就可以配合使用。一旦标准确定，双方各自实现。这样，服务器可以支持更多支持标准的框架，框架也可以使用更多支持标准的服务器。

• WSGI（Web Server Gateway Interface）就是一种规范，它定义了使用Python编写的web应用程序与web服务器程序之间的接口格式，实现web应用程序与web服务器程序间的解耦。常用的WSGI服务器有uwsgi、Gunicorn。而Python标准库提供的独立WSGI服务器叫wsgiref，Django开发环境用的就是这个模块来做服务器。

from wsgiref.simple_server import make_server
# wsgiref本身就是个web框架，提供了一些固定的功能
# （请求和响应信息的封装，不需要我们自己写原生的socket了也不需要咱们自己来完成请求信息的提取了，提取起来很方便）
# 函数名字随便起


def application(environ, start_response):
    """
    :param environ: 是全部加工好的请求信息，加工成了一个字典，通过字典取值的方式就能拿到很多你想要拿到的信息
    :param start_response: 帮你封装响应信息的（响应行和响应头），注意下面的参数
    :return:
    """
    # 设置响应类型和状态码
    start_response('200 OK', [('Content-Type', 'text/html'), ('k1', 'v1')])
    # print(environ)
    # 输入地址127.0.0.1:8080，这个打印的是'/',输入的是127.0.0.1:8080/index，打印结果是'/index'
    print(environ['PATH_INFO'])
    return [b'<h1>Hello, web!</h1>']


if __name__ == '__main__':
    httpd = make_server('127.0.0.1', 8080, application)
    print('Serving HTTP on port 8080...')
    # 开始监听HTTP请求:
    httpd.serve_forever()

使用模板操作文件

from wsgiref.simple_server import make_server
# wsgiref本身就是个web框架，提供了一些固定的功能
# （请求和响应信息的封装，不需要我们自己写原生的socket了也不需要咱们自己来完成请求信息的提取了，提取起来很方便）
# 函数名字随便起


def index():
    with open("index.html", "r") as f:
        data = f.read()
    return data


def article():
    with open("article.html", "r") as f:
        data = f.read()
    return data


def application(environ, start_response):
    """
    :param environ: 是全部加工好的请求信息，加工成了一个字典，通过字典取值的方式就能拿到很多你想要拿到的信息
    :param start_response: 帮你封装响应信息的（响应行和响应头），注意下面的参数
    :return:
    """
    # 设置路由
    urlpatterns = [
        ('/index', index),
        ('/article', article)
    ]
    # 设置响应类型和状态码
    start_response('200 OK', [('Content-Type', 'text/html'), ('k1', 'v1')])
    # print(environ)
    # 输入地址127.0.0.1:8080，这个打印的是'/',输入的是127.0.0.1:8080/index，打印结果是'/index'
    # print(environ['PATH_INFO'])
    # return [b'<h1>Hello, web!</h1>']
    path = environ['PATH_INFO']
    for item in urlpatterns:
        if path == item[0]:
            ret = item[1]()
            break
    else:
        ret = '404 not found!'
    return [ret.encode('utf-8')]


if __name__ == '__main__':
    httpd = make_server('127.0.0.1', 8080, application)
    print('Serving HTTP on port 8080...')
    # 开始监听HTTP请求:
    httpd.serve_forever()

模板自己写，后面使用jinja2模板

安装 pip3 install jinja2

MVC和MTV框架

MVC

Web服务器开发领域里著名的MVC模式，所谓MVC就是把Web应用分为模型(M)，控制器©和视图(V)三层，他们之间以一种插件式的、松耦合的方式连接在一起，模型负责业务对象与数据库的映射(ORM)，视图负责与用户的交互(页面)，控制器接受用户的输入调用模型和视图完成用户的请求，其示意图如下所示：

M:models数据库相关；V：views视图相关 C：controller控制器 url分发

MTV

Django的MTV模式本质上和MVC是一样的，也是为了各组件间保持松耦合关系，只是定义上有些许不同，Django的MTV分别是值：

• M 代表模型（Model）： 负责业务对象和数据库的关系映射(ORM)。
• T 代表模板 (Template)：负责如何把页面展示给用户(html)。
• V 代表视图（View）： 负责业务逻辑，并在适当时候调用Model和Template。

除了以上三层之外，还需要一个URL分发器，它的作用是将一个个URL的页面请求分发给不同的View处理，View再调用相应的Model和Template，MTV的响应模式如下所示：

M:models数据库相关； T：templates模板 html文件 ；V：views视图相关 + url分发

一般是用户通过浏览器向我们的服务器发起一个请求(request)，这个请求回去访问视图函数，（如果不涉及到数据调用，那么这个时候视图函数返回一个模板也就是一个网页给用户），视图函数调用模型，模型去数据库查找数据，然后逐级返回，视图函数把返回的数据填充到模板中空格中，最后返回网页给用户。

路由

• 举例什么是路由？假如你在上大学的时候，睡觉起晚了，醒来后发现宿舍同学都走光了，你想到上午还有课，但是不记得去哪个教室去上了，这时候你会查下课程表，然后就知道去哪个教室上课了。这个课程表就是你的路由。

• 网络中的路由器，路由器主要是在网络中做数据转发，连接Internet各个局域网和广域网，让他们互通，当我们打开一个浏览器访问网页的时候，请求的数据包要到达一个远程的服务器要经过路由器的层层转发。

• 在ASP.NET MVC中，路由有相似的作用，路由就是将输入的网页地址和控制