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 {

   

    当然,最佳实践只是一种约定,不是强制!

 

   

    

你可能感兴趣的:(spring,mvc,框架,Flex,IOC)