MTV模式
# Django MVT 模式
M：Model, 模型 与MVC中的M相同，负责对数据的处理
V：View, 视图 与MVC中的C类似，负责处理用户请求，调用M和T，响应请求
T：Template, 模板 与MVC中的V类似，负责如何显示数据（产生html界面）
# 说明:
# Django也是MVC框架。
Django框架（内部的URLconf)作为控制器的角色，负责了接收用户请求和转发请求的工作，Django 里更关注的是模型（Model）、模板(Template)和视图（Views），故称之为 Django MVT 模式
处理过程： Django框架接收了用户请求和参数后，再通过正则表达式匹配URL，转发给对应视图进行处理。视图调用M处理数据，再调用T返回界面给浏览器；
MVC模式
# MVC: Model-View-Controller 模型-视图-控制器
M： 数据处理 V： 界面显示 C： 逻辑处理
上个世纪八十年代为Smalltalk语言发明的一种 软件框架模式。最开始用于Desktop程序开发，现在已被广泛使用，包括Web开发。
核心思想： 分层，解耦。MVC分离了 数据处理 和 界面显示 的代码，使得程序可以在不修改数据处理相关逻辑的前提下，方便地切换不同的显示界面
目的： 提高程序的扩展性和可维护性。
# Web开发中的MVC：
M： model层，负责对数据的处理，包括对数据的增删改查等操作
V： view层，负责显示model层的数据
MVC的核心思想就是模型的复用，模型不用关心处理结果展现，比如模型返回一些数据，然后交给不用的视图展现，可以使用不同的视图来访问同一个模型；
代码方便维护，比如修改模型不会影响到视图（模板），反过来修改视图，也不会影响到模型；方便测试， 比如，将业务逻辑代码写在servlet里面，需要部署到容器上，然后才能测试。
而将业务逻辑代码写在类里面，可以直接用main()测试（不依赖容器）
# mvc的缺点
使用mvc，会增加代码量、相应地也会增加软件开发的成文，设计的难度也会增加,适合大型项目。
（1）视图跟控制器过于紧密的连接，（视图与控制器是相互分离，但却是联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。
【例如，不可能总是在jsp页面中直接访问模型，一般放在逻辑控制层进行处理，servlet】）
（2）增加了系统结构和实现的复杂性
（3）部分高级界面工具或构造器不支持MVC
（4）视图对模型数据的访问效率低（依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。
【例如，页面的有一部分数据我并没有更新，但是提交到模型层照样会去获得返回显示 】）
（4）调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。
简单的小型项目，使用MVC设计反而会降低开发效率，层和层虽然相互分离，但是之间关联性太强，没有做到独立的重用
