1. 首先,在稍大一点的项目中,pureMVC的消息传递会成为一个比较严重的瓶颈。

  2. 其次, 使用麻烦。先要定义消息,注册消息,创建command,注册command,分发command,处理command等等。绝大多数情况下,程序需要处理的只是command中携带的数据,而非command本身,以上步骤完全是不必要的。

  3. 太过于灵活。一个框架,如果既可以这样使用,也可以那样使用,那么用户基本上不知道该怎么使用。pureMVC的消息传递并非只有一条路径。Message和Notification可以在很多地方发起。当一个框架的使用需要用文档而不是代码本身来规范,这个框架的设计通常都是不知所谓的。

这三点是互相影响的。比如,考虑到灵活、强大,必然会导致性能问题,以及使用上的复杂化。 对于框架上的选择,并不推荐使用类似的设计。这种设计模式的框架,和通常的库框架——比如MFC——不同,并不能提供任何功能上的好处,实在是没引入的必要,特别是对那些规模较大的项目。

Comments

2012-08-17