对PureMvc的一些印像

本质上Notification只是一个简单类，Notifaction能做的，Event同样能做。

例如你说到的权限、log等切面功能，你可以写一个继承自Event的子类CustomEvent，然后系统中用到的自定义的Event都统一继承CustomEvent。

我这里强调的是在系统中引入Notification这个概念后，增加了系统的复杂性、增加了学习成本。但它究竟带来了什么好处？

我觉得Notification加的挺好的很有必要，诚如你所说，notification就是个简单类，但event可不简单！用event来做notification正式你所说的增加复杂性。

咱就不说可移植性的问题了，胡乱找个借口吧:名字真的很重要，因为望文生义是我们的本能，我们要可读性。名字起的不好会让我们晕头的，如果同是event，多少会造成混乱的，你不混乱新手也是会混乱的。
flex的event机制，要求handler和target要碰面，所谓target.addEventListener(eventType,handler),没有解耦这两者，这在模块内部使用还没啥问题，一旦要求跨模块就不现实了，Notification机制中发送消息的对象Notifor和处理消息的Command是互相不知道彼此的，这从Notification这个词的本意也能体会出来。所以我说event和Notification是两个层次的东西。当然你可以说用event转手一次转到消息队列再处理来实现，但是明显有区别的东西，你为什么不用一个新的东西来标志他呢？非要继承event里的那一大坨一会儿currentTarget一会儿target一会儿preventDefault还能stopImmediate这不纯属误导人嘛。

我觉得PureMvc也是概念太多，实际用起来比较麻烦。就为了解耦，把逻辑分开，有点过。它又不是强制性的，程序用了PureMvc不一定是解耦的，复杂很容易用错。做Flex有组件的概念，也是MVC的，把组件概念用好就已经不错了。如果纯用actionscript开发，有个PureMvc这样的东西还是不错的。还是要根据项目选择，适合的才是好的。

http://raptureinvenice.blogspot.com/2008/08/why-and-how-i-switched-from-puremvc-to.html（要翻墙）

以PM的角度，PUREMVC是一个很不错的选择。

flex开发不使用框架，等着维护的时候哭吧。。。如此自由的语言，没有框架的约束，代码的可读性急剧下降，维护的成本急剧上升。

目前只用过2个框架，另一个是烟水晶那东东。两害相权取其轻，个人觉得puremvc更好用一些。

至今已使用该框架近2年了吧。目前依然在用，在多个项目，不同环境下用过，感觉依然很好。强烈推荐各位使用。

对于UI层，个人有几个观点：

一、这一层既然选择了动态语言，从某角度说明在这一层中我们更需要的是灵活。没必要引入mvc框架把自已套死。

二、一方面mvc框架是不需要的，但另一方面mvc模式还是要有。基本的表现层、业务层、通迅层、域对像层可以按项目规模适度分开。而统一分包及命名更是必不可少。

另外，PM我没做过，但小系统还是设计过几个,经典的是用储存过程写工作流引擎，经过几个版本的迭代到最后的维护也不难，更没有哭过。

所以我建议大家在UI层不要用MVC框架，取而代之的是根据项目规模，团队状况对UI层进行适当的分层和做好编码约束。