https://zhuanlan.zhihu.com/p/33733161

我的结论是：大部分项目都不适合，尤其是PureMVC。甚至某些情况下，都不必执着于MVC，且可以简化成M（VC）。

PureMVC的框架设计如下：

为了实现“极致”的解耦，实现最大限度的复用，PureMVC在原有的MVC基础之上，添加了很多中间层（图中的Facade、Proxy、Command、Mediator），并且制定了一套比较严格、繁杂的层与层之间的交互方式。先抛开这些繁杂的概念、中间层能不能被每个团队成员正确理解不说。真正利用这套方案写出来的代码，变成另一个人甚至自己去维护扩展的时候，成本就大大提高了。

PureMVC最大的优点在于，各逻辑模块之间的耦合度很低，方便各模块的重复利用。但是我们得从实际出发，反思我们的项目模块复用有没有这么频繁、UI界面的逻辑变化程度是否必须需要我们提前隔离好，管控起来。比如，假如我们的UI方案在Android、IOS上是分别单独实现的两套方案，那么就有必要独立出一个Mediator出来，隔离View与UI解决方案的耦合，从而在这两个平台上复用View的代码，而不是写一份“重复”的代码。代码越多，BUG越多，这个道理应该都知道。假如我们没有这种情况，那么仍然独立出Mediator是极其不划算的。依次类推，对于游戏UI逻辑而言，绝大部分逻辑都不存在复用的情况。所以PureMVC的绝大部分中间件，在游戏开发过程中绝大部分情况下都没有存在的必要性。

PureMVC架构出来的代码，几乎无法通过人眼简单快速的定位问题。往往要跟着消息事件流，跟很长的一段流程，才能清楚各个模块的调用关系。对于C#这种强类型的静态语言还好，要是遇到lua这种动态脚本语言，可以说是一种灾难。往往需要自己ctrl+f，来在不运行调试的情况下，大概理清整个界面的逻辑流程。一旦代码可读性差，那么自己或者别人修改起来，犯的错误肯定就多。可以说，PureMVC大大增加了团队理解维护代码的成本，这是其缺点。

综合PureMVC的优点和其缺点，本人觉得PureMVC仅仅只适合处理跨平台，且业务交互复杂的项目。但是当业务交互场景复杂多变的时候，比如两套UI系统，两套数据访问系统等等。此时应该做的事情是整合“重复”的系统，反而如果用PureMVC，只会使得整个项目更加复杂和难以维护。

MVC用C来“隔离”M和V，从而达到一定程度上的M、V的复用。MVVM用VM来“隔离”M和V，也达到了一定程度上的复用性。综合前面所说，低耦合会增加维护调试成本，且对游戏界面逻辑而言，复用程度和变化程度相当低。在增加了成本的情况下，反而没有好好的享受到低耦合带来的利益，是不划算的。

但是MVVM相比PureMVC，没有那么复杂，可读性相对较强。且如果自己工具流做的比较好的话，完全可以让团队的UI程序猿只就着工具生成出来的VM开发M层逻辑，界面由美术或者策划拼好，而根据VM刷新V的代码也由工具自动生成。这样虽说牺牲了一定的代码可读性，但是在data binding完善好之后，UI界面的开发效率会大大的提高。UI程序猿就不用在界面的Hierarchy，和代码之间来回切换，且不用编写“简单”的V刷新代码，让电脑帮我们写就好。初期改完工具的底层BUG之后，工具生成的刷新V代码、VM数据结构几乎不用再查阅，出BUG只管先查阅M层就好。这便是我会选择用MVVM的最大原因。如果没有完善的工具流，选用MVVM对我们来说，不够划算。

最后想说，有人可能会不大同意我说的，游戏界面逻辑复用程度、变更程度很小。经常拿换皮啊，策划脑洞大改界面之类的作比。这些其实大家可以细想下，最好是实际操作下。真的没有哪一种方案能让你少干点活，MVC要改的东西，PureMVC也要改、MVVM也会要改，有些甚至还会让你改更多的地方。PureMVC、MVVM等架构方案，其实只是相当于给我们“练字”的方格本，让我们把字方方正正的填到方格中央。但当我们真正理解了我们的需求，明确了我们的设计目的，并熟练掌握了《设计模式》，我们其实可以用更简单优雅的方式，来达到我们的目的。我们做设计的人，应该谨慎的权衡好各种设计的成本。