pureMVC的争议,说说缺点

pureMVC的争议,说说缺点...

pureMVC的优点资料很多,他实现多种设计模式,解耦彻底,灵活度非常高,重用性高,易扩展.

 写这篇文章仅表达本人的怀疑精神,如有不对,请指教学习.

首先先链两篇我搜到的文章
PureMVC 的得与失
pureMVC优缺点

 

<设计模式：可复用面向对象软件的基础>说过一点,为适合的程序选择适合的设计模式,其它介绍设计模式相关的书都有提过类似的观点.pureMVC底层实现了多种设计模式,但是,那些并不是提供我们在适合的时候去用,而是约束各模块开发时,必须去用.

Controller是无状态的,读了里面的代码会知道,controller是消息绑定Class对象,其实就是消息过来时controller会跟椐消息对应的class创建一个临时对象,调用完里面的方法就销毁.大家都知道new多用会影响性能,大型项目消息很多,一个事件可能会导致半秒数秒的延迟.

命令模式大多是用于日记,记录,撤销等关系处理,而pureMVC把所有命令都对象化了,冗余和流程拉长是肯定的. 

Notification的官方说法是为了兼容其它平台而弃用了内置的event,事实上Notification所提供的功能是不够的,比如我们并不知道Notification的源头.即谁发的.还有一点,adobe官方的事件机制的效率性能都比pureMVC自写的方法高.个人觉得这块应该留个接口供用户选择. 

消息机制是pureMVC用来解耦最多的方法.不过个人觉得消息机制不应乱用,我们试想一个例子,网页提交数据后页面某组数据全加1后刷新.用pureMVC的操作是mediator收到ui提交事件后发个消息给controller,controll进行业务逻辑处理,后发消息绘proxy,proxy再找出要加1的对象更新,再然后发消息给mediator刷新.这个长长的流程,表面是四步,但是加上了消息帧听和接收,其实流了8步.而这个过程中,因为都是消息机制,要调试这个过程我们只能在编译的时候才能一步步找发来的是什么对象,(或者遍历消息对象的方法),应该用什么类去as它.可能我举的例不是很好,但暂时没想出别的了,有经验的可以类堆.

很多设计模式书中都提过,观察者模式适用于1对多关系的处理.而在一个项目中,view要触发的controller大多数是一对一的,还是个人觉得,至少mediator跟controller的交互没必须用到消息.而controller跟proxy的消息解耦代码的很多时候是多余的.

 

有人说pureMVC易维护,本人并不认为,大量的消息发送接收调试起来其实很困难. Actionscript不像java支持泛型,而且消息机制更容易让消息对象无类型.比如我一个vo的属性改个名后,IDE并不能报错,类型引用错时只能编译的时候才知道.修改调试起来不方便.而我更愿意继承官方event加写有类型的对象. 

关于解耦的方法很多,事件,消息只是其中一种,多读flash api的类会发现adobe并不是乱用事件,因为事件是无类型引用的,所有处理事件adobe十分小心.继承/覆盖/组合都可以让代码复用而且易读易调试.

解耦合是为了代码复用,而复用是为了让下一个项目不敲这么多代码,速度更快点.大量的消息的管理虽然是做到了复用,但是下个项目的速度并没达合理的快这个效果.(我的意思是部分模块如果不纯用消息的话,下个项目复用会更快)

 

不过解耦来来去去就是接口,抽象类,消息几种方法;接口,抽象类来解耦的缺点是接口,抽象改了,实现全都得跟着改.消息的解耦就很灵活,不管方法属性随意添删,不过缺点就是本文所说的.

 

补一段,很多新手不知道解耦,复用是什么意思(我当年就是这样),可以试试考虑写一个GUI组件.写的过程思考怎么让另一个程序使用这套GUI,(比如重写,听消息,组合来使用).

 

https://www.cnblogs.com/pelephone/archive/2012/02/24/pureMVC-actionscript-faults.html