为什么选择Parsley?

Flex企业应用的常用框架有Cairngorm、Parsley、PureMVC、Swiz、Robotlegs,那我们为什么对Parsley情有独钟呢?业界有种说法是:没有最好的框架,只有“更好”的框架,满足项目的框架才是好的。理想的框架应该是:

  • 灵活。没有一个绝对的唯一“正确”的做事方式。能帮助你实现目标的设计模式就是“正确”的。
  • 具备强大的解耦消息机制。比Cairngorm更好的方式是消息应当能够以解耦方式,从任一地方发送到任何地方,最好能限制在特定的上下文(范围)内。
  • 允许使用Flex模块轻松集成。这一点很重要。
  • 有助于解耦。该框架有助于实现反转控制(IOC)。
  • 简化依赖注入。你并不需要一个框架来使用依赖注入。
  • 允许存在模型范围或上下文。子模型只可在共享的上下文共存。
  • 易扩展易维护。随着项目的发展,可以很容易重新分解任务。
  • 简单易学,迅速上手。

为什么不选择Cairngorm呢?

  • 有限的解耦消息机制。Cairngorm多使用CairngormEvent,发送和接收对象对框架来说不是完全解耦的。
  • 滥用单例。单例使用起来是很方便,但它不存在特定的模型范围。在多窗口应用中使用单例模型,下一个窗口中对模型的修改可能会覆盖在上一个窗口中的修改。单例在单模块中是全局的,但在多模块应用之间不能直接访问。
  • 缺少Flex模块支持。模型和前端控制器都是用单例实现的,不能在模块之间直接访问。

当然这些问题在Cairngorm 3中这些有所改善。

为什么不选择其它框架呢?

  • PureMVC面向多语言设计使其在实现时太依赖于Mediator,不够敏捷,牺牲了Flex sdk的特性。
  • Mate简单但太依赖于MXML。尤其是Map文件,本身是MXML文件,不应该处理逻辑,不方便重构维护。
  • Swiz消息必须是Flex事件,也不能像Parsley那样可以自动或手动控制生命周期,没有Parsley成熟灵活。
  • Robotlegs作为后起之秀,设计思想和Parsley类似,但在Robotlegs中定义上下文对象只能使用ActioScript,而Parsley除了ActionScript外,还支持元数据标签、MXML和XML多种方式。

我曾与Parsley的作者Jens Halm同在一个项目组,可惜我还没进项目组,这位大神已经离开了。幸好还有机会与另一位大神Tom Sugden共事,他是《Adobe Flex 3高级编程》的作者之一。

发表评论