parsley最佳实践

    上篇博文提道：“目前，Flex框架大致可分为两大类，一类是正规军MVC--Cairngorm&pureMVC，一类是自由军MVC兼IOC--swiz、mate、parsley、spring as。正规军的MVC是在既定模式下运作整个流程，而这个模式的形成是以解耦为原则的职责划分，优点自然是权责清晰，而其不足在于过于正规化使得工作量或效率被转嫁，一个看似小小的需求，也要动辄整个流程，使得小需求付出过多（即程序员编码量过大）。”

    我们知道，事物均具有双重性，因此，根据事物的双重性，我们再来分析一下第二类框架--自由军的MVC不强制划分职责，但提供了事件或消息的通信机制保障期间的沟通，当然，这些分工可以根据项目团体来自行负责建设。因此，自由也是有代价的，但这种代价换来无尽的灵活性从某些方面来讲也是值得的。相信自Spring问世以来，大家对IOC的概念以及其带来好处都并不陌生，是啊，IOC也是一种很好的“好莱坞”式解耦思想啊。因此，融入IOC的支持也是这类自由军框架的另一优点。接下来，我们简单认识一下Flex自由军框架parsley的最佳实践。

    最佳实践一、关于注入

    ①前提：针对接口编程，采用类型注入方式，保证接口实现惟一；结论：AS3 metadata tag注入依赖DI & parsley MXML配置IOC容器托管对象；较为官方推崇！

    ②前提：无法满足①的前提保证接口实现惟一，需采用id注入方式；结论：依赖DI与parsley IOC容器托管对象均通过MXML配置完成！

 

    最佳实践二、关于配置

    采用AS3 metadata tag & parsley MXML。

 

    我们知道，对于parsley IOC容器提供的DI，支持以下几种方式：
    1、AS3 Metadata tags；
    2、MXML
      2.1、普通MXML；
      2.2、Parsley MXML；
    3、XML；
    4、混合模式（以上几种配置的混用）。
    需要注意的是，MXML配置方式仅适用于Flex，而不适用于Flash；

    既然有这么多种配置方式，那么为何要执行最佳实践呢？原因在于这几种配置的优劣势对比，详情如下：

普通MXML、parsley MXML与XML对比：
普通MXML优势：①简单直观；②无需了解parsley配置标签；③编译器检测属性值类型；
parsley MXML优势：
①允许构造器注入（即支持标签[InjectConstructor]）；
②允许将对象指定为lazy加载模式（<Object lazy="true" type="..."/>，默认为false)；
③允许配置对象为DynamicObject/non-singleton：相比于<Object>标签，<DynamicObject>标签为每次请求创建一个新的对象实例。
XML优势：①经常变动配置而避免重复编译；②无编程知识人员编辑配置文件或不使用Flex；
XML编译警惕：与配置在MXML中的类相比，配置在XML中的类，若没有显式在代码中使用或引用，它们将不被编译到SWC或SWF中。解决之道有3，①显式在代码中引用类（比较丑陋）；②编译成SWC类库（If you want to use these classes as a library, compile them into an SWC (with compc you can include whole source folders into the SWC) and then include the whole SWC into your SWF with the -include-libraries option of the mxmlc compiler.）；③以参数的方式告诉编译器（You can alternatively include individual classes with the -includes option of the mxmlc compiler.）。
MXML与XML配置在写法上的异同性
MXML 和 XML 配置几乎是一样的，细小的不同是标记的不同,MXML支持驼峰式书写方式，而XML支持带关联线"-"的小写方式(capitalized camel-case vs. lower case names with dashes).样例参见《parsley2.2指南-DI/IOC依赖注入-配置文件中声明依赖》

AS3 Metadata tags继承性（从mxmlc编译器使用的规则看）：
1、类级别的metadata tag永远不会被继承到其子类；
2、属性或方法级别的metadata tag，若不被其子类覆盖写，则可被继承到子类（即在其子类依旧可用）；若被子类覆盖写，只有当其覆盖写的方法或属性自身没有任何metadata tag修饰时，则可被继承到子类。
3、关于[ProcessSuperclass][ProcessInterfaces]
出于性能的考虑（Flash player反射速度相当慢），一般情况下，任何类级别的metadata tag被其子类忽略，但是，这也许不是某些场合/情况所期待结果，比如类拥有很多冗长的[ManageEvents]期待继承到子类中，对于这些特殊需求，框架提供了可选的显式标签，[ProcessSuperclass][ProcessInterfaces]分别用于子类或接口的特定实现类；需要注意的是：
①传递性
[ProcessSuperclass]将被传递到所有其子类以及子类的子类；[ProcessInterfaces]将被传递到所有其实现类；
②不可覆盖性
无法覆盖写这两个标识使其终结传递性；
如：
[ProcessSuperclass][ProcessInterfaces]
public class SomeClass {

   

    当然，最佳实践只是一种约定，不是强制！