MVC vs MVP

MVP 一种由传统的 MVC 模式演变而来开发模式。MVC 和 MVP 都有一个共同的地方，就是 Model (M) 负责数据的存取，View (V) 负责界面的显示，Controller (C) 与 Presenter (P) 负责业务逻辑的处理。但是两者最大的不同点就是 View 与 Model 之间的交互方式，在 MVC 中 V，View 允许去直接访问 Model，而在 MVP 中是不可以的，View 与 Model 之间的交互完全由 Presenter 来负责。

Android 中的 MVC

在 Android 中，Controller 的职责落在了 Activity 中，而 Activity 负责加载 XML 中的布局显示在界面上，对 View 中的控件的访问也在 Activity 中完成，所以 Activity 变得 “很重”，遇到复杂的界面时，代码量动辄成百上千行，隔段时间再去维护该块代码时，那种痛，可想而知~

MVP 在 Android 中的应用

1. Activity V 层只负责界面的显示，业务逻辑交给 P 层处理，P 与 V 直接通过接口通信。
2. P 层收到 V 层的交互请求，负责调用 M 层来处理数据，处理完后通知 V 层更新界面。
3. P 层与 M 层也通过接口进行通信，P 层处于 V 与 M 之间的中介，负责调度 V 与 M。

MVP 模式的优点：

• 实现 View 与 Model 的解耦

  View 与 Model 之间的通信需要通过 Presenter 来完成，修改界面不影响模型，修改模型不影响界面。

• 逻辑更清晰，易于维护

  使用 MVP 后，View 只负责界面的显示，看起来非常干净，不至于过两天再来看就成了 “别人的代码”

• P 层与 M 层复用

  如果项目中有类似的界面，可以直接复用 Presenter 或者 Model 层

• 适合多人协同开发

  如果一个页面太复杂可以实现多人共同开发，开发之前事先定义好 V 与 P、P 与 V 之间的接口（接口后期根据开发来修改），然后可以让一个人负责界面，另一个人负责业务逻辑，之间使用接口进行通信。

• 单元测试

  可不依托于界面来单独进行业务逻辑的测试

MVP 模式的缺点：

• 代码量变多，需要定义很多接口，类文件增多
• 需要控制好一些特殊对象的生命周期，防止内存泄漏的问题

总结

MVP 模式没有正确的写法，MVP 只是一个思想，根据需求适合自己项目才是正确的。页面逻辑越复杂，MVP 的优势越明显，所以如果遇到简单的界面，可以不使用 MVP。