对PureMvc的一些印像

       学习了一下PureMVC，写了笔记：读书笔记：puremvc framework implementation idioms and……。以下是对PureMVC的一些印像：

 

优点：
一、模式用得多，看文档的过程感觉就像把23种基本模式复习了一次。[用了多少模式，具体没数过。但23种模式中，也用得七七八八了]。所以就算学了PureMVC后不使用也不浪费学习时间。

 

二、解耦，整个系统都由中间层及Notification机制解耦了。[是否解耦得太过份了？]

 

 

缺点：
1、角色（类形）太多，角色间关系复杂（一对多，多对多）。

 

 

2、过份依赖观察者模式、配置零散、不方便维护及调试：

一、PureMvc推崇的是解耦，但解耦直接的结果就是单靠IDE（ctrl+点击）根本找不到代码调用的路线。代码每到一处就是发送一个Notification。然后调用路线就断了。要继线就要找配置。看了官方的demo(appskeleton)，配置的地方是分散的。Command在facade中的配置，Mediator中对notification的配置、Proxy……。

 

 

二、别人可能说，UI本来就是事件模型。调用关系本来就没有服务端明确。其实这个不一定。如果把事件限制在一些特定层中，调用关系还是很明确的。

 

 

3、需要编写的额外代码烦多。

 

 

4、不提供额外功能。
Spring提供声名式事务支持。Hibernate简化持久层操作。PureMVC提供什么额外功能？

 

 

以下是我对框架中一些角色的理解：

 

一、Mediator的角色我基本认同。它把mxml元素布局与as逻辑分开。但对Mediator中的Notification的映射我觉得这些是多余代码。而switch结构用在这里，我觉得也不优美。另外在调用proxy时，先从facade获取obj，再转形为实现类，转了一大圈回到了原点，显得多余。而这种转化与Spring的工厂也没有可比性。

 

 

二、Proxy的角色我也免强认同。Proxy的作用类似于服务端的“瘦模型”。Model只用作数据容器，Proxy处理域逻辑。“瘦模型”用在客户端。其实也可以。但在proxy发送notification。我反对，我上面说过，事件（观察者模式）用在特定层可以接受，但事件惯穿业务层、惯穿整个系统。我反对。

 

 

三、Command的角色我也认同。其实就是业务层，没什么可说的。

 

 

四、facade的角色我不认同。反正代码最后import的都是实现类。这个facade不多余吗？

 

 

五、Notification这个角色我不认同。as已内置事件模式，没必要自已增加一个观察者模块。另外notification的用法，我也不认同。

 

 

总结：PureMVC的作用很大程度上是解耦。但我对这种解耦程度很有疑问。它带来的好处与它带来的缺点比例多大？

 

最后虽然我对PureMVC持反对态度，但存在即合理，而且有这么多人支持。PureMVC也肯定有他的过人之处。希望有PureMVC实践经验的出来指导指导。