[悖论]MVC、MVP、MVVM有优劣之别吗

偶然间，看到一个说法：AJAX是针对MVC的，不符合MVVM的浪潮。

引发了一个思考：MVC、MVP、MVVM有优劣之别吗？

过往面试也曾有人问我这个问题。
本文的目的，不是介绍MVC、MVP、MVVM是什么了。
MVP较MVC出现的晚，的确也是因为某些缺陷出现了这样的方案，MVVM又因为MVP的某些缺陷出现。

究竟孰优孰劣？笔者的观点：这本身就是个错误的思考点，一个埋雷的坑。

若MVC<MVP<MVVM，假定顺序是这样的。
那么，你就应该通盘采用有较大优势的一个。

笔者认为，这MVC、MVP、MVVM没有任何优劣可比。仅仅只是适用的场景不一样罢了。

• 场景一：打开一个页面，简单的请求某个string，然后，显示出现。

  • 谁愿意用MVP、MVVM。我第一选择是用一个最简洁的类 extends 某BaseMVC，直接了解的，调用设置。一个文件足矣。
  • 倘若用MVP，你是不是起码得4个文件。类的数量多了。维护成本变高，你难道不累？

• 场景二：复杂页面，API调用多，但展示什么，逻辑还是蛮清晰的。

  • 你当然不应该用MVC，这样显得Activity极其庞大。
  • 用Contract定义接口。确实会显得更清晰。

• 场景三：复杂页面，API调用多，关键是某些API变，Response值多样，但页面却不大动。

  这个时候，你又选择什么呢？

MVC、MVP、MVVM是编程技巧，并没有什么优劣之分，差异的是使用场景。

我认为大部分时候，你不会用到MVVM，因为这种场景少。能出现这种场景，我相信，后端或者产品设计需要优化了。
在平时研发过程中，我更多的会结合MVC、MVP的使用，速战速决。一个页面，除了UI费时，接口对接的耗时，可以得到很大的压缩。

同样的道理，设计模式有很多，但是有一个叫混合模式。