无意间在一个游戏工程中接触到了这个MVC架构，整个工程都覆盖着一层设计模式的耀眼光环，深深地被它吸引住了。随后了解到这个框架在零几年便推出，覆盖了16种语言红极一时，后来家道中落，便慢慢的被人遗忘了。
官方给出的IOS版本竟然只更新支持到3.0，已经完全不能适应现今这个环境。不过总算在这里找到了IOS版本的源码，便兴致勃勃地研究了两天。
主体架构
iOS中的MVC架构中Controller与View经常被合二为一了，由于UIViewController的存在，开发者往往会将所有的代码都填进去，慢慢的UIViewController就会越来越臃肿。
在PureMVC中，强制开发者将业务区分成Controller/View/Mode三个实体，并分别用Command/Mediator/Proxy模式对这三个实体进行抽象分离，这样很好地解决了UIViewController臃肿及View与Controller功能区分不清的问题。
MVC模块间通信机制
PureMVC架构中各模块间的通信是建立在观察者模式的基础之上，先来看下通知的具体定义：
name是一个通知的惟一标识，开发者需要确保该标识的惟一性。
type是通知的类型，标识一类通知的不同类型。
body是通知发出时传递给接收方的参数。
再来看下通知的发送体系UML图：
Mediator/Proxy/Command都是Notifier的子类，也就是说它们都可以发送通知。IMediator的接口中有一个handleNotification:方法，没错这个就是处理通知的方法，也就是说只有Mediator类能够处理通知。
Notifier类中有IFacade的引用，也就是说Mediator/Command/Proxy对象中都可以获得IFacade的引用，IFacade的UML结构如下图：
Facade在设计模式里又被叫做门面模式，说的是一个系统的所有子系统使用统一的接口交互。Facade又被设计成了一个单例类，它包含着Controller/Model/View这三个单例类的引用。
这样所有的Mediator/Proxy/Command对象都可以通过Facade间接地与其它任何对象通信，不过这样就违背了PureMVC设计通知系统来削减Model/View/Controller三者之间耦合的本意了。
通知系统的典型用法是Controller发送通知，View接收到通知，处理数据后刷新界面显示，然后更新数据到Model。View能够直接调用Model的接口，但Model却不关注View，Model数据发生变化时，只需要发送特定的通知即可。
典型用法
这里给出一个参考项目，从项目的结构中我们能感觉到该架构的优雅，将传统的各种UIViewController分解成了一个个的Command操作。将开发者的关注点从一个界面分解成了一组操作，总体上给人一种非常清爽的感觉。
繁琐
上面的工程实际上只有两个UIViewController页面，但我们可以看到大大小小的十个类：
界面对应了一个View类与一个Mediator类，View类只作界面显示的功能，Mediator类控制View如何显示、并与其它Controller/Model交互
UIViewController上的各种动作被抽象成了一个个Command类，这些Command类也占据了整个工程类数目的半壁江山。而实际上这些Command的作用只是给Mediator或者Proxy发送某个通知。
这也是我认为PureMVC最不爽的一点，为了达到解耦的效果，拿起了一把手术刀，把整个项目分解成了一小块一小块的碎片，在项目页面较少时还比较清爽，在项目界面繁多时，这些碎片堆叠在一起就让人头大了。
缺陷
最大的缺陷就是这个项目老早就不更新了，可以说已经死掉了。还有就是资源比较少，这也可以算是上面的衍生物吧。
结语
虽然使用的人少之又少，但其MVC的思想也有着独特的光芒，建议大家了解并在实际开发过程中使用下。
