1、Django（MVT模式）
由python实现的，开源的，Web开发框架
起初被开发来用于管理劳伦斯日报（Lawrence Journal-World）旗下的新闻内容网站
2005年7月在BSD许可协议下发布
Django是一个比利时音乐家的名字
注重代码复用，强调DRY原则(don’t repeat yourself)，可以帮助开发者快速地创建复杂的网站
2、MVC
1、介绍1
核心思想：解耦
浏览器请求发送给Controller，Controller把需求发给Model,Model返回数据给Controller,Controller把数据传送给View渲染，View返回给浏览器编程模式
Model（模型）：应用程序中处理数据逻辑的部分、通常模型对象负责在数据库中存取数据、业务逻辑和实体模型(biz/bean)
View（视图）：处理数据显示的部分、通常视图是依据模型数据创建的、布局文件(XML)
Controller（控制器）：处理用户交互的部分、负责从视图读取数据，通知用户输入，并向模型发送数据、控制器(Activity)优点：降低了各功能模块之间的耦合性，方便重构代码，最大程度上实现了代码重用
2、介绍2
MVC: Model-View-Controller 模型-视图-控制器
M： 数据处理、model层，负责对数据的处理，包括对数据的增删改查等操作
V： 界面显示、view层，负责显示model层的数据
C： 逻辑处理上个世纪八十年代为Smalltalk语言发明的一种 软件框架模式。最开始用于Desktop程序开发，现在已被广泛使用，包括Web开发。
核心思想： 分层，解耦。MVC分离了 数据处理 和 界面显示 的代码，使得程序可以在不修改数据处理相关逻辑的前提下，方便地切换不同的显示界面
MVC的核心思想就是模型的复用，模型不用关心处理结果展现，比如模型返回一些数据，然后交给不用的视图展现，可以使用不同的视图来访问同一个模型；代码方便维护，比如修改模型不会影响到视图（模板），反过来修改视图，也不会影响到模型；方便测试， 比如，将业务逻辑代码写在servlet里面，需要部署到容器上，然后才能测试。而将业务逻辑代码写在类里面，可以直接用main()测试（不依赖容器）
MVC的缺点
使用MVC，会增加代码量、相应地也会增加软件开发的成文，设计的难度也会增加,适合大型项目。
（1）视图跟控制器过于紧密的连接，（视图与控制器是相互分离，但却是联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。【例如，不可能总是在jsp页面中直接访问模型，一般放在逻辑控制层进行处理，servlet】）
（2）增加了系统结构和实现的复杂性
（3）部分高级界面工具或构造器不支持MVC
（4）视图对模型数据的访问效率低（依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。【例如，页面的有一部分数据我并没有更新，但是提交到模型层照样会去获得返回显示 】
（5）调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。
简单的小型项目，使用MVC设计反而会降低开发效率，层和层虽然相互分离，但是之间关联性太强，没有做到独立的重用
3、MVT
1、介绍1
本质与MVC没有区别，各组件之间为了保持松耦合关系
编程模式
Model（模型）：负责业务对象与数据库的对象（ORM）
View（视图）相当于MVC里的Controller、负责业务逻辑，并在适当时候调用Model和Template
Template（模板）相当于MVC里的View、负责把页面展示给用户
注意：Django还有一个url分发器，作用是将一个个URL分发给不同的View处理说明：
1.用户输入URL，通过URL控制器进行正则匹配，匹配到相应的视图函数，交给视图处理；
2.视图交给Model去取数据，Model取完数据返回给视图；
3.视图再把需要展示的数据传给模板（就是html页面）
2、介绍2
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返回界面给浏览器；Django follows the MVC pattern closely, however it does use its own logic in the implementation. Because the “C” is handled by the framework itself.
Django严格遵循MVC模式，但它在实现中使用了自己的逻辑。因为“C”是由框架本身处理的。
4、MVVM
1、介绍1
M-Model : 实体模型(biz/bean)
V-View : 布局文件(XML)
VM-ViewModel : DataBinding所在之处，对外暴露出公共属性，View和Model的绑定器
2、介绍2
对比MVP和MVVM模型图可以看出，他们之间区别主要体现在以下两点：
- 可重用性。你可以把一些视图逻辑放在一个ViewModel里面，让很多View重用这段视图逻辑。 在Android中，布局里可以进行一个视图逻辑，并且Model发生变化，View也随着发生变化。
- 低耦合。以前Activity、Fragment中需要把数据填充到View，还要进行一些视图逻辑。现在这些都可在布局中完成（具体代码请看后面） 甚至都不需要再Activity、Fragment去findViewById（）。这时候Activity、Fragment只需要做好的逻辑处理就可以了。
5、MVP
1、介绍1
MVC相信大家都熟悉这个框架，这个也是初学者最常用的框架，该框架虽然也是把代码逻辑和UI层分离，但是View层能做的事情还是很少的，很多对于页面的呈现还是交由C实现，这样会导致项目中C的代码臃肿，如果项目小，代码臃肿点还是能接受的，但是随着项目的不断迭代，代码量的增加，你就会没办法忍受该框架开发的项目，这时MVP框架就应运而生。
2、介绍2
M-Model : 业务逻辑和实体模型(biz/bean)
V-View : 布局文件(XML)和Activity
P-Presenter : 完成View和Model的交互MVP框架相对于MVC框架做了较大的改变，将Activity当做View使用，代替MVC框架中的C的是P，对比MVC和MVP的模型图可以发现变化最大的是View层和Model层不在直接通信，所有交互的工作都交由Presenter层来解决。既然两者都通过Presenter来通信，为了复用和可拓展性，MVP框架基于接口设计的理念大家自然就可以理解其用意。
但MVP框架也有不足之处:
1.接口过多，一定程度影响了编码效率。
2.业务逻辑抽象到Presenter中，较为复杂的界面Activity代码量依然会很多。
3.导致Presenter的代码量过大。
