Android架构MVCMV和MVVM.pptVIP

4.MVC与MVP对比 因此我们可以发现MVP的优点如下： 1、模型与视图完全分离，我们可以修改视图而不影响模型； 2、可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部； 3、我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁； 4、如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）。 具体到Android App中，一般可以将App根据程序的结构进行纵向划分，根据MVP可以将App分别为模型层(M)，UI层(V)和逻辑层(P)。 具体到Android App中，一般可以将App根据程序的结构进行纵向划分，根据MVP可以将App分别为模型层(M)，UI层(V)和逻辑层(P)。 UI层一般包括Activity，Fragment，Adapter等直接和UI相关的类，UI层的Activity在启动之后实例化相应的Presenter，App的控制权后移，由UI转移到Presenter，两者之间的通信通过BroadCast、Handler或者接口完成，只传递事件和结果。 举个简单的例子，UI层通知逻辑层（Presenter）用户点击了一个Button，逻辑层（Presenter）自己决定应该用什么行为进行响应，该找哪个模型（Model）去做这件事，最后逻辑层（Presenter）将完成的结果更新到UI层。 4.MVC与MVP对比 尽管MVC设计的非常nice，但代码臃肿的问题仍然没有得到很好的解决，这个时候MVP就要登场了。可以看到MVP相对于MVC改动是非常大的。Activity直接当做View使用，代替MVC中C的是P-Presenter。对比MVC和MVP的模型图可以发现变化最大的是View和Model不在直接通信，所有交互的工作都通过Presenter来解决。既然两者都通过Presenter来通信，为了复用和可拓展性，MVP模式基于接口设计也就很好理解了。两者都通过Presenter来通信，好很多的好处，例如提高代码复用性啦、增加可拓展性啦、降低耦合度啦、代码逻辑更加清晰啦。但是、本来两个能直接通信的东西现在要通过第三方来通信，那势必会增加很多类。没错，MVP模式虽然很好，但是增加了很多的接口和实现类。代码逻辑虽然清晰，但是代码量要庞大一些。当刚接手一个烂尾的MVP模式，如果事先没了解过MVP，会不会一脸的懵逼。所以MVP比较适用于中小型的项目，大型项目慎用。 四、MVVM M-Model : 实体模型(biz/bean) V-View : 布局文件(XML) VM-ViewModel : binder所在之处，对外暴露出公共属性，View和Model的绑定器 MVVM可以算是MVP的升级版，其中的VM是ViewModel的缩写，ViewModel可以理解成是View的数据模型和Presenter的合体，ViewModel和View之间的交互通过Data Binding完成，而Data Binding可以实现双向的交互，这就使得视图和控制层之间的耦合程度进一步降低，关注点分离更为彻底，同时减轻了Activity的压力。 有的读者该说了，你作用这不是和MVC一样嘛！是的，对应的文件看起来确实是一样的，但是作用不同。MVVM和MVP一样，View和Model不允许直接交互。只能通过ViewModel。MVVM神奇的地方在于通过ViewModel隔离了UI层和业务逻辑层，降低程序的耦合度。而且，布局文件里可以进行视图逻辑！并且Model发生变化，View也随着发生变化。布局文件里居然还能写逻辑，斯国一！ 1、MVVM 2.MVC-MVP-MVVM演进过程 MVC - MVP - MVVM 这几个软件设计模式是一步步演化发展的，MVVM 是从 MVP 的进一步发展与规范，MVP 隔离了MVC中的 M 与 V 的直接联系后，靠 Presenter 来中转，所以使用 MVP 时 P 是直接调用 View 的接口来实现对视图的操作的，这个 View 接口的东西一般来说是 showData、showLoading等等。M 与 V已经隔离了，方便测试了，但代码还不够优雅简洁，所以 MVVM 就弥补了这些缺陷。在 MVVM 中就出现的 Data Binding 这个概念，意思就是 View 接口的 showData 这些实现方法可以不写了，通过 Binding 来实现。 3.MVVM代码实例 WTF！居然只有Activity、Bean以及一个activity_main.xml？是的，MVVP就是这么简洁。可是简洁不意味着简单。Google去年I