关于MVC，MVP，MVVM的一点总结和思考

简介

软件的架构方式有很多种，从最开始的MVC模式，演化到MVP，然后到现在的MVVM，在不断的演化过程中其核心的思想就是降低各组件之间的耦合度，使得数据的流向更加的清晰明了。但并不是意味着一个比另一个高级，只是对于软件的架构方式有的不同的视角，针对不同的场景有了更多的选择方案。在学习过程中通过对三种架构方式的比对和思考，可以很好的帮助我们提高对于软件架构的理解，以下只是自己学习过程中的一点总结和反思，由于水平有限，有意见或者是观点请各位看官指正。

什么是架构

在谈具体的架构之前我们需要先明白什么叫做架构，而他们又有什么作用，为什么会被广泛的使用。个人对于这个问题是这样认为的：架构就像是一个人的骨骼一样，或者是像是机器人的整体框架一样，他决定了之后所有的操作是基于一种什么样的方式上展开的，就像是乐高积木一样。

以机器人为例，最简单的机器人就是各个模块之间相互焊接组成的，将四肢焊接到躯干的电路板上，这样就会产生一个问题。就是当某一个部位损坏时需要将对应部位替换，但是由于所有的连接点都是直接焊死的，所以在后期的维修过程中很麻烦。但是若是我们在设计初期就将所有的连接点设计成即插即用的接口，那么当有零件损坏时，只需要将损坏的零件拔下，然后用新的零件直接替换就好，这样的设计无疑是更加科学合理的。

在软件开发过程中也是一样的，架构其实就是之前例子中的不同的焊接方式，不同的架构可以使我们有着不同的组织软件的方式，并不一定是说哪一个最好，而是根据其使用的场景来选择最为合适的架构方式。选用合适的架构，可以有助我们实现软件的合理分层，降低耦合度，便于后期的维护和拓展。

MVC（Model，View，Control）

较为传统和成熟的一种架构方式，最核心的就是通过Control层来进行调控，所有的调度都是由Control来进行处理。其核心的策略简示如下：

可以看到在这种模式中，Control处于中间核心地位，同时三者之间是两两都有联系的。这种模式在JavaEE中的SSH框架体现的很好，页面展示（View）使用JSP和Struct，同时将业务逻辑的处理（Control）交给具体的Action，然后Action会通过对应的DAO层（Model）来进行数据的更新，然后再将更新的数据返回给Action，Action根据DAO层的返回来控制页面的跳转。这就很好的将整个软件实现了分层，下层为上层提供服务的接口，而上层对下层进行汇总调用。这就是MVC框架的直观体现，可以很好的将软件架构进行分层，降低了耦合度。

而在Android中，Model主要包括对于数据的增删改查操作，服务器数据的拉取等这些和数据相关的工作，View主要包括各种组件和自定义的View，Control则主要是Activity。但是有一个问题就是，由于Activity同时也需要承载View，处理UI视图的变化，但是同时也需要处理业务逻辑，这样的话Activity就会显得很臃肿，在后期阅读起来会很困难，同时对于它的定位也就很模糊。代码就会有很高的耦合性，在后期的维护中也就很困难。

###优缺点：

• 优点： 优点是对于混乱的软件组织方式有了一个明确的组织方式，通过Control来掌控全局，同时将View展示和Model的变化分离开。

• 缺点： 从图示中也可以看出，在View和Model之间是直接进行交互的，也就是说View和Model之间是可以相互产生影响的，这样在代码中就必然会导致View和Model之间的耦合。

MVP（Model，View，Presenter）

关于MVP的架构方式可以看我之前的一篇学习文章： Google官方推荐MVP基础示例学习总结

MVC架构方式的变种，使用Presenter来代替Control，而且改变了数据的流向，View和Model之间不再直接进行交互，而是全部通过Presenter来进行。

则MVP架构中，Presenter同时持有View和Model，同时View和Model中也各自含有对于Presenter的引用。当View中的视图改变，需要更新数据时，通过Presenter来通知Model来进行数据更新，同样的当数据发生更新时，也通过其自身含有的额Presenter引用来通知View来进行更新。这样Presenter就可以作为桥梁来联系两者，而传统的Activity只需要进行UI的绘制，呈现即可。

优缺点：

• 优点： 优点是可以是得整个软件分层清晰，降低耦合度，同时也将Activity从既是Control又是View的境地中解脱出来，只需要单一的负责UI即可，降低了Activity的任务

• 缺点： 缺点是需要加入Presenter来作为桥梁协调View和Model，同时也会导致Presenter变得很臃肿，在维护时比较不方便。而且对于每一个Activity，基本上均需要一个对应的Presenter来进行对应。

MVVM（Model，View，ViewModel）

关于MVVM的详细可以阅读我之前的一篇关于MVVM的是个实现框架的的文章Google官方支持的MVVM架构框架DataBinding使用入门但是这只是Google推出的实现MVVM架构的一个框架，并不是说MVVM就只是DataBinding

MVVM其实是对MVP的一种改进，他将Presenter替换成了ViewModel，并通过双向的数据绑定来实现视图和数据的交互。也就是说只需要将数据和视图绑定一次之后，那么之后当数据发生改变时就会自动的在UI上刷新而不需要我们自己进行手动刷新。在MVVM中，他尽可能的会简化数据流的走向，使其变得更加简洁明了。

优缺点：

• 优点： 可以使得数据流的走向更加的清晰明了，同时也简化了开发，数据和视图只需要进行一次绑定即可。
• 缺点： 目前这种架构方式的实现方式比较不完善规范，常见的就是DataBinding框架

关于三种模式的其他文章：

http://www.ruanyifeng.com/blog/2015/02/mvcmvp_mvvm.html