安卓mvc mvp,androidmvc和mvp

　　MVVM模式MVVM模式(ModelViewViewModel mode)，与MVP模式相比，MVVM模式用ViewModel代替了Presenter，其他层与MVP模型基本一致-View-ViewModel可以理解为View的数据模型和Presenter的组合。

　　视图：对应Activity和XML，负责绘制视图，与用户交互。模型：实体模型。ViewModel:负责视图和模型的交互，负责业务逻辑。MVVM的目标和理念与MVP相似。它使用数据绑定、依赖属性、命令和路由事件等新功能来构建更加灵活高效的体系结构。

　　MVVM采用数据绑定：视图的变化自动反映在ViewModel中，反之亦然。这种模式实际上意味着框架为应用开发者做一些工作(相当于库为我们生成的ViewModel类)，开发者只需要较少的代码就可以实现复杂的交互。这一步对我更有吸引力，可以少写很多模板代码。

　　在Google I/O 2015官方大会上，推出了支持MVVM模式的数据绑定库。Android Studio 2.1预览版3之后开始支持双向数据绑定，即在视图层修改输入也会触发模型层的变化。

　　当然，做过WinPhone开发的人一定记得，微软使用MVVM模式已经很多年了。

　　数据驱动在常规开发模式下，当UI因数据变化需要更新时，需要先获取UI控件的引用，再更新UI。获取用户的输入和操作也需要UI控件的引用。在MVVM，这些都是通过数据驱动自动完成的。数据变化后UI会自动更新，UI变化可以自动反馈到数据层，数据成为主导。这样，MVVM层在业务逻辑处理中只关心数据，不需要直接处理UI，所以在业务处理上简单方便很多。

　　在低耦合MVVM模式下，数据独立于UI。

　　和数据业务逻辑都在独立的视图模型中。ViewModel只需要关注数据和业务逻辑，不需要处理UI或者控件。UI想要对数据做什么取决于UI本身。ViewModel不涉及任何与UI相关的东西，也不包含对UI控件的引用。即使更改了控件(比如TextView更改为EditText)，ViewModel几乎不需要更改任何代码。它完美的解耦了视图层和视图模型，解决了上面提到的MVP的痛点。

　　在MVVM更新用户界面。数据发生变化后，我们可以直接在工作线程中修改ViewModel的数据(当数据是线程安全的时候)，就不用考虑切换到主线程来更新UI了。相关框架为我们做了所有这些事情。

　　协同MVVM的分工非常明显，因为View和ViewModel是松耦合的：一个是处理业务和数据，一个是处理专门的UI。所以完全是两个人来做，一个做UI(XML和Activity)，一个写ViewModel，效率更高。

　　可重用性视图模型可以在多个视图中重用。相同的数据可以提供给不同的用户界面进行显示。对于版本迭代中频繁的UI更改，只需更新或添加一组视图即可。如果你想在UI上做A/B测试，那么MVVM是你最好的选择。

　　单元测试有些同学看到单元测试可能头都大了。是的，怎么可能通过编写一堆代码来进行单元测试呢？如果你因为代码太差写不出单元测试而逃跑，那真的是个坏消息。在这个时候，你需要MVVM来拯救。

　　前面说过，ViewModel层做的是数据处理和业务逻辑，View层专注的是UI，两者完全独立。无论是UI的单元测试，还是业务逻辑的单元测试，都是低耦合的。在MVVM，数据是直接绑定到UI控件的(有些数据可以直接反映UI的内容)，所以我们可以通过直接修改绑定的数据源来间接对Android UI做一些测试。

　　通过以上的简要描述和车型对比，我们可以发现MVVM的优势还是非常明显的。目前，虽然在Android开发中可能真正使用MVVM的人很少，但还是值得我们做一些讨论和研究。

　　MVC、MVP、MVVM选择如果项目比较简单，复杂度不大，以后变化不大，那么就不要用设计模式或者架构方法，只是把每个模块打包好方便调用，不要为了用设计模式或者架构方法而用。对于面向显示的应用程序，大多数业务逻辑都在后端。app的主要功能是展示数据、交互等。建议使用mvvm。对于需要写很多业务逻辑的工具类或者app，可以用mvp或者mvvm。如果想通过一个项目学习架构和设计模式，建议先用MVC，然后在这个基础上慢慢摸索完善。最后你可能会发现，改进的最终结果可能会变成mvp，mvvm。参考https://tech.meituan.com/2016/11/11/android-mvvm.html

　　版权归作者所有：博主曲乐优香原创作品，转载授权请联系作者，否则将追究法律责任。

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。