1>server端扩展问题
先看下之前的socket-server端，如下
现在还好，只有两个页面，一个login，一个index，但实际项目中一个网站都是包含成百上千个页面的，若是按照上面的
写法，我们必须要写成百上千个判断语句，后期维护的工作量，不可想象，
要改，绝对要改。
2>把上面看起来很乱的代码我们分下层，或者说分下共，明确下每一个代码块负责的事儿，进行代码解耦，如下。
恩，上面这样一写，代码看起来就“灵活”多了，试想，我现在要是想再加一个访问页面，就比如注册页面reg
如果我已经有了reg.html，那么上面的代码要做的改动就很小了，
1>在视图层加入对应的path和reg的处理函数
2>对应编写下reg函数，
就OK了， 是的， 就两步，其他的都不必考虑，
3>再优化下
上面的代码已经有一些“框架”的影子了，框架就是把我们需要重复干的事情封装好，让我们不必再位置操心，我们
只需专注于web业务逻辑开发，就行，
代码肯定是越来越多的，都“挤”在一个文件肯定不行，既然上面已经分出了类似“处理函数”“视图层”等代码块，
我们干脆把他们移入各自的文件里面，单独存放，再引用，这样更具层次感，减低后期维护难度。
改装如下：
先看文件结构
templates里面包含web的静态网页，也就是所有的html文件，也有一种专业叫法----------模板层
controller.py里面包含所有的处理函数，负责读取模板层的html并返回，也有涉及数据库交互的（
比如账号密码登陆验证，需从数据库取值对比等等），专业叫法----------------------------控制层
view.py里面包含所有的路径（path）和处理函数的对应关系。专业叫法-------------------视图层
server.py就是整个web应用的入口函数了，一般都改名为main.py或者manage.py，恩恩
这样，整个简单的小框架就显得非常的pythonic了，
4>补充
基于这个简单的框架，我们想扩展功能，需要做啥
写前端 html，放入 templates里面，再于view.py里面增加路径和处理函数的对应关系记录，再controller.py
编写对应的处理函数，没啦，就这些，这，，，就是框架带来的便利。
而且上面拆分过程无形当中引入了Web服务器开发领域里著名的MVC模式，所谓MVC就是把Web应用分为模型(M)，
控制器(C)和视图(V)三层，他们之间以一种插件式的、松耦合的方式连接在一起，模型负责业务对象与数据
库的映射(ORM)，视图负责与用户的交互(页面)，控制器接受用户的输入调用模型和视图完成用户的请求，
但是python里面不叫MVC，叫MTV，其实核心思想和理念基本一致，只是这个叫法不同。
后续的Django其实也就是基于这样一种开发思想而建立的体系，其核心跟上面的那一套简单的框架差不多，只是Django
在功能方面，在一些特性/细节处理方面要多得多，这，也是我们学习Django的一大主要原因。
既然引出了Django，就先介绍下Django的MTV模式和流程。
Django的MTV模式本质上和MVC是一样的，也是为了各组件间保持松耦合关系，只是定义上有些许不同
- M 代表模型（Model）： 负责业务对象和数据库的关系映射(ORM)。
- T 代表模板 (Template)：负责如何把页面展示给用户(html)。
- V 代表视图（View）： 负责业务逻辑，并在适当时候调用Model和Template。
除了以上三层之外，还需要一个URL分发器，它的作用是将一个个URL的页面请求分发给不同的View处理，View再调用相应的Model和Template，MTV的响应模式如下所示：
用户首先输入URL访问web应用，这时候，首先经过URL控制器（类似函数主入口了，main.py），
控制器会根据urls.py里面路径和处理函数的对应关系，
找到view.py（类似上面小框架的controller.py）的真正的处理函数，执行函数
函数执行过程当中首先肯定要去找templates下面的HTML文件，读取文件并返回给用户，
其中可能还涉及到数据库操作，去数据库里取数据等等，那就要操作models.py（专门与数据库交互的文件）
最终返回结果给视图层，再一并返回给用户（例如，账号密码登录，用户输入账号密码，点击登陆，此时post请求发过来，
server这边先找到对应的处理函数，处理函数发现需要进行数据对比，就去数据库取出账号密码进行对比，若是匹配正确，
就发送给用户一个登陆成功的页面，若是不匹配，就返回给用户一个登陆失败的页面。-------------这整套流程刚好就是
用户请求-->URL控制器-->view.py-->models.py-->templates-->返回给用户）