MVC MVP MVVM
MVC MVP MVVM浅谈，MVC、MVP和MVVM都是为了解决界面呈现和逻辑代码分离而出现的模式。MVC作为最经典的开发模式之一，经典的MVC模式是M-V-X模式的老祖宗，MVP和MVVM都是在MVC的基础上演化而来，和MVC框架模式一样，Model模型处理数据代码。这些架构的目的都是为了提高代码的复用率、降低代码的耦合度、便于模块测试、版本的迭代更新，下面对每个架构进行简单的介绍与使用。
- MVC
- MVP
- MVVM
MVC
M：模型 业务逻辑处理
V ：视图 处理数据显示
C： 控制器 Activity处理用户交互问题
特点：①：耦合性低。②：可扩展性好。③：模块划分明确。
activity厚重，业务扩及复杂。实际上Activity即显示视图，又控制逻辑。
View既依赖于Controller又依赖于Model，解耦程度不足。
MVP
M：依然是业务逻辑和具体实体模型。
V：对应activity，负责view的绘制以及用户交互。
P：负责完成View与Model质检的交互。
区别： Presenter将View与Model分离，使得View和Model之间不存在耦合，同时也将业务逻辑从View中抽离。所有的业务逻辑由Presenter主持者来控制。
数据Model通过Presenter和View交互，比MVC耦合性更低。
优点：模块职责划分明显,增加可测试性与可扩展性，隐藏数据,降低了程序的耦合度，提高了代码的重用性与灵活性。
缺点：视图的渲染在Presenter中，所以视图和Presenter的交互会过于频繁。如果Presenter过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。
一旦视图需要变更，那么Presenter也需要变更了
MVVM
1View：对应于activity和xml，负责view的绘制和用户交互。
2.model：实体模型
3.ViewModel：负责完成View和Model间的交互，负责业务逻辑。
MVVM模式：采用双向绑定（data-binding）：View的变动，自动反映在 ViewModel，反之亦然。
ViewModel主要包括界面逻辑和模型数据封装，Behavior/Command事件响应处理，绑定属性定义和集合。
优点：便于代码移植，兼容MVC，方便测试，降低了程序的耦合度，提高了代码的重用性。
缺点：类会增多，ViewModel会越加庞大，调用的复杂度增加。
书到用时方恨少，纸上得来终觉浅。希望可以帮助到您。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/115049.html原文链接：https://javaforall.net
