什么是 Parsley？拿官方的话来说，它是一个用于 Flex 和 Flash 应用程序的应用程序框架，建立在 IOC 容器和消息传递框架上，可用于创建高度松耦合架构。它允许你通过元数据、MXML、XML 或 ActionScript 配置由容器托管的对象，并且很容易扩展。
Parsley 的特性
- IOC 容器。Parsley 是一个典型的 IOC 容器。它为依赖注入、对象生命周期管理和消息传递提供了支持。
- 依赖注入。IOC 容器的核心功能。依赖关系可以方便地使用 ActionScript 3.0 元数据标签（
[Inject]）、MXML 或 XML 在属性、方法或构造函数上声明。 - 消息传递。消息传递允许对象用完全松耦合的方式来发送和接收消息。你可以用
[MessageDispatcher]元数据标签来标记一个 Function 类型属性，当你想传递一个消息实例到系统时就调用它，系统会按路线发送给注册的接收者。接收对象可以用一些诸如[MessageHandler]之类的元数据标签来关联特定消息类型。 - 松耦合绑定。类似于 Flex 绑定，不同的是目标并不需要知道绑定的源。源发布一个属性上标有
[Publish]的对象，那么任何其他可能会收到更新的值的对象需要在属性上标记为[Subscribe]。 - 管理命令。支持基于独立的 Spicelib 命令框架。它允许命令执行的时候容器才自动将它们添加到上下文。用 MXML 和 XML 标签来声明命令或命令的序列。它允许映射命令到消息，所以每个匹配的消息引起一个新的命令被实例化并执行。作为一种选择，命令工厂也可以注入到托管对象中来手动执行。
- 对象生命周期。对象可以有标记为
[Init]（将在对象实例化和配置之后调用）或者[Destroy]（将在容器摧毁的时候调用）的方法。异步初始化对象的配置选项(如对象，需要加载数据才能操作 )，在这种情况下，容器将延迟其他对象的初始化，直到这些配置为异步准备好了。 - 动态视图装配。解决了使用 MXML 视图层次结构不用在 IOC 容器配置文件中声明 Flex 组件，Parsley 允许将这些组件添加到舞台的时候和 IOC 容器即时连接。还解决了在 Flex 弹出窗口或原生 AIR 窗口中装配组件之类更复杂的问题。
- 支持模块化应用程序。可以创建可配置的子上下文，并且在需要的时候可以动态的加载和卸载他们。无缝地集成了 Flex 模块，但是也可以不使用。框架允许一个非常细粒度的上下文层次结构，使它能方便的在你的应用程序里为单独的窗口，弹出窗口或标签页创建特定范围或上下文。
- 本地化。允许用
[ResourceBinding]标签绑定属性和资源。为 Flex 应用程序集成了 Flex ResourceManager，并且包含 Flash 应用程序它自己的本地化模块。 - 扩展性。Parsley 可以作为基础来构建高层次的框架。或者你可能只是想为用例创造一些额外的配置标签，对那些对应用程序使用频繁的操作。Parsley 是很容易扩展的。
后续教程我们将针对大部分特性编写一个简单的实例以加深对 Parsley 的理解。
- 非侵入性。根本没有必要为了使用 Parsley 的特性而扩展原有的类，很多功能用简单的标签就实现了，这些标签在其它框架中可能无法解释而忽略，但不影响其它框架对其它代码的执行。这就是所谓的框架独立。
- 非强迫性。Parsley 不强迫你使用特定和设计模式。这就是所谓的框架解耦。你可以遵循 MVC 模式，或者使用其他任何解耦模式。
- Managed Objects（管理对象）：Parsley 只会管理想要管理的对象。非视图组件（那些没有添加到舞台的）使用 ContextBuilder 进行管理，视图组件（那些通过 addchild() 方法添加到舞台的）使用 Configure 标签进行管理。Parsley 管理通过 ContextBuilder 添加的对象的整个生命周期，它会根据需要自动创建新实例，并在不需要的情况下删除旧实例。如果你想要 Parsley 管理的类作为构造函数的参数，Parsley 也能做到。一般来说，当视图组件从舞台移除也会同时从所属上下文移除，最后一个视图根从舞台移除相关的上下文自身也会自动销毁。（除非特别声明它不要这么做）。
- Context（上下文）：上下文在 Parsley 中有点类似于类的范围。 在同一上下文的对象彼此是可见的，在同一上下中可以共享其他任何管理对象。与范围一样，上下文可以嵌套，就像你在 ActionScript 3.0 中用花括号{}来控制范围。有趣的是，Parsley 通过自动和动态装配视图来实现上下文。也就是说，一旦一个组件创建了上下文，该容器的任何子视图都可以使用它。这也意味着你可以很容易地创建和管理嵌套的上下文、多层级上下文、子上下文、甚至你想调用的私有上下文。
- Dynamic View Wiring（动态视图装配）：默认情况下，Parsley 的上下文与视图层次结构相联系。组件的视图子组件，或它的子类，都加入相同的上下文，这适用于整个视图层次结构。这样做的好处是，你不需要有两个层次结构(一个用于 Parsley 另一个用于视图 )，而且这只需极少额外配置。这也适用于模块，如果一个模块被当作视图子组件加载添加，它将作为其父容器所在上下文的一部分自动加入。
- IOC（反转控制）模式又称 DI（依赖注入）：是一个重要的面向对象编程的法则，也是一种设计模式。主要是协调各组件间相互的依赖关系，同时大大提高了组件的可移植性，组件的重用机会也变得更多。在传统的实现中，由程序内部代码来控制程序之间的关系。我们经常使用 new 关键字来实现两组件间组合的关系，这种实现的方式会造成组件之间耦合(一个好的设计，不但要实现代码重用，还要将组件间关系解耦 )。IoC 很好的解决了该问题，它将实现组件间关系从程序内部提到外部容器来管理。也就是说由容器在运行期将组件间的某种依赖关系动态的注入组件中。控制程序间关系的实现交给了外部的容器来完成。即常说的好莱坞原则，即 你呆着别动，到时我会找你。Parsley 为我们管理依赖注入，它托管对象并在需要它们时候注入，因此可以很容易地添加新的功能。
- Singletons（单例）。Parsley 的文档有时使用术语 singleton。单例模式本质上是一个类有且只用一个实例，Parsley 的文档通常所指的单例是在特定上下文中的单一实例，而不是在整个应用程序的单一实例。
- Reflection（反射）：反射是一种计算机程序能够检查自己和潜在的使用这些信息来改变它在运行时的行为的能力。Flash 和 ActionScript 的反射是一种强大的功能。反射对于 Parsley 意味着它可以按照你的要求阅读和检查类、调用方法、阅读和分配那些没有在应用程序显式地进行编码的类属性。通过反射，Parsley 可以知道你想使用框架管理依赖注入，将一个特定实例的对象分配给另一个类的属性。
为什么选择 Parsley？
Flex 企业应用的常用框架有 Cairngorm、Parsley、PureMVC、Swiz、Robotlegs，那我们为什么对 Parsley 情有独钟呢？业界有种说法是：没有最好的框架，只有更好的框架，满足项目的框架才是好的。理想的框架应该是：
- 灵活。没有一个绝对的唯一正确的做事方式。能帮助你实现目标的设计模式就是正确的。
- 具备强大的解耦消息机制。比 Cairngorm 更好的方式是消息应当能够以解耦方式，从任一地方发送到任何地方，最好能限制在特定的上下文（范围）内。
- 允许使用 Flex 模块轻松集成。这一点很重要。
- 有助于解耦。该框架有助于实现反转控制（IOC）。
- 简化依赖注入。你并不需要一个框架来使用依赖注入。
- 允许存在模型范围或上下文。子模型只可在共享的上下文共存。
- 易扩展易维护。随着项目的发展，可以很容易重新分解任务。
- 简单易学，迅速上手。
- 有限的解耦消息机制。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 高级编程》的作者之一。
评论 (0)