三张图让你看清MVC、MVP、MVVM

作者: 醉馬当前闯 | 来源:发表于2016-06-13 00:17 被阅读1184次

    MVC

    MVC,Model View Controller,是软件架构中最常见的一种框架,简单来说就是通过controller的控制去操作model层的数据,并且返回给view层展示,具体见下图

    当用户触发事件的时候,view层会发送指令到controller层,接着controller去通知model层更新数据,model层更新完数据以后直接显示在view层上,这就是MVC的工作原理。

    那具体到Android上是怎么样一个情况呢?

    大家都知道一个Android工程有什么对吧,有java的class文件,有res文件夹,里面是各种资源,还有类似manifest文件等等。对于原生

    的Android项目来说,layout.xml里面的xml文件就对应于MVC的view层,里面都是一些view的布局代码,而各种java

    bean,还有一些类似repository类就对应于model层,至于controller层,就是各种activity。大家可以试着套用

    我上面说的MVC的工作原理是理解。比如你的界面有一个按钮,按下这个按钮去网络上下载一个文件,这个按钮是view层的,是使用xml来写的,而那些和

    网络连接相关的代码写在其他类里,比如你可以写一个专门的networkHelper类,这个就是model层,那怎么连接这两层呢?是通过

    button.setOnClickListener()这个函数,这个函数就写在了activity中,对应于controller层。是不是很清晰。

    MVP

    MVP

    作为MVC的演化,解决了MVC不少的缺点,对于Android来说,MVP的model层相对

    于MVC是一样的,而activity和fragment不再是controller层,而是纯粹的view层,所有关于用户事件的转发全部交由

    presenter层处理。

    从图中就可以看出,最明显的差别就是view层和model层不再相互可知,完全的解耦,取而代之的presenter层充当了桥梁的作用,用于操作

    view层发出的事件传递到presenter层中,presenter层去操作model层,并且将数据返回给view层,整个过程中view层和

    model层完全没有联系。看到这里大家可能会问,虽然view层和model层解耦了,但是view层和presenter层不是耦合在一起了吗?其实

    不是的,对于view层和presenter层的通信,我们是可以通过接口实现的,具体的意思就是说我们的activity,fragment可以去实现

    实现定义好的接口,而在对应的presenter中通过接口调用方法。不仅如此,我们还可以编写测试用的View,模拟用户的各种操作,从而实现对

    Presenter的测试。这就解决了MVC模式中测试,维护难的问题。

    当然,其实最好的方式是使用fragment作为view层,而activity则是用于创建view层(fragment)和presenter层(presenter)的一个控制器。

    MVVM

    它和MVP的区别貌似不大,只不过是presenter层换成了viewmodel层,还有一点就是view层和viewmodel层是相互绑定的关系,这意味着当你更新viewmodel层的数据的时候,view层会相应的变动ui。

    MVC缺点:

    问题就在于xml作为view层,控制能力实在太弱了,你想去动

    态的改变一个页面的背景,或者动态的隐藏/显示一个按钮,这些都没办法在xml中做,只能把代码写在activity中,造成了activity既是

    controller层,又是view层的这样一个窘境。大家回想一下自己写的代码,如果是一个逻辑很复杂的页面,activity或者fragment

    是不是动辄上千行呢?这样不仅写起来麻烦,维护起来更是噩梦。(当然看过Android源码的同学其实会发现上千行的代码不算啥,一个

    RecyclerView.class的代码都快上万行了呢。。)

    MVC还有一个重要的缺陷,大家看上面那幅图,view层和model层是相互可知的,这意味着两层之间存在耦合,耦合对于一个大型程序来说是非常致命的,因为这表示开发,测试,维护都需要花大量的精力。

    MVP缺点:

    MVP的问题在于,由于我们使用了接口的方式去连接view层和presenter层,这样就导致了一个问题,如果你有一个逻辑很复杂的页面,你的接口会有很多,十几二十个都不足为奇。想象一个app中有很多个这样复杂的页面,维护接口的成本就会非常的大。

    这个问题的解决方案就是你得根据自己的业务逻辑去斟酌着写接口。你可以定义一些基类接口,把一些公共的逻辑,比如网络请求成功失败,toast等等放在里面,之后你再定义新的接口的时候可以继承自那些基类,这样会好不少。

    MVVM缺点:

    MVVM的问题呢,其实和MVC有一点像。data

    binding框架解决了数据绑定的问题,但是view层还是会过重,activity在MVVM中应该是view层的,但是里面却和MVC一样写了对

    model的处理。有人会说你可以把对model的处理放到

    viewmodel层中,这样不是更符合MVVM的设计理念吗?这样确实可以,但是progressDialog的show和dismiss呢?你怎么在

    viewmodel层中控制?这是view层的东西啊,而且在xml中也没有

    相关文章

      网友评论

      • 小编:其实没有哪一种最好,只是看哪种模式更适合当前的业务。DataBinding感觉只是实现了数据的绑定,一部分脱离了findViewById的苦海,但是如果遇到业务复杂的场景,还是MVP更合适。或者将两者结合——MVPVM
      • 苍蝇的梦: :flushed: :flushed: :flushed: 每次看到这种都是一大堆文字,都没见过小demo,完全没法去理解自己写的对不对
        小编:我建议应该找些基本资料先去理解用法和思路,在回过头来纵观全局思想,方能领悟。
        小编:所以应该先去搜索相关资料理解了概念和用法,在回过头看这些理论方能领悟
        醉馬当前闯:@拾荒者老大 关于这些确实比较难写出形象demo

      本文标题:三张图让你看清MVC、MVP、MVVM

      本文链接:https://www.haomeiwen.com/subject/eqcydttx.html