Prana是一个面向 Adobe Flex及ActionScript 3的控制反转(Inversion of Control,即IoC)应用框架。控制反转(Ioc)模式(又称DI:Dependency Injection)就是Inversion of Control,控制反转,IoC意味着将你设计好的类交给系统去控制,而不是在你的类内部控制。这称为控制反转。
IoC(Inversion of Control)是近年来兴起的一种思想,不仅仅是编程思想。主要是协调各组件间相互的依赖关系,同时大大提高了组件的可移植性,组件的重用机会也变得更 多。在传统的实现中,由程序内部代码来控制程序之间的关系。我们经常使用new关键字来实现两组键间关系的组合,这种实现的方式会造成组件之间耦合(一个 好的设计,不但要实现代码重用,还要将组件间关系解耦)。IoC很好的解决了该问题,它将实现组件间关系从程序内部提到外部容器来管理。也就是说由容器在 运行期将组件间的某种依赖关系动态的注入组件中。控制程序间关系的实现交给了外部的容器来完成。即常说的好莱坞原则“Don't call us, we'll call you”。
看下面使用了Prana的示例:
- <object id="myRemoteObject" class="mx.rpc.remoting.mxml.RemoteObject">
- <property name="destination" value="GenericDestination"/>
- <property name="endpoint" value="http://localhost/project/weborb.aspx"/>
- <property name="source" value="com.domain.project.SomeService"/>
- </object>
对应的destination定义:
- <destination id="myDestination">
- <properties>
- <source>com.domain.project.SomeService</source>
- </properties>
- </destination>
如IoC模式所述,每一个类的示例化交给了container去完成,而不是直接使用new关键字。使用Ioc后在需 要实例类代码中将不需要嵌入任何工厂模式等的代码,彻底解耦了类之间的联系。与IoC紧密联系的是AOP(面向切面的编程)模式,但是AVM不支持 dynamic proxy mechanism,即在运行时动态加载并编译一个Class(除非事先将该Class加载进AVM),所以基于Flash Player的AOP编程还不太现实。
当然使用Ioc带来的代价是:需要在客户端或其它某处进行类之间联系的组装。这样很麻烦,像许多 Java工程一样,配置文件满天飞。值得思考的是,究竟在什么情况下需要用到这样的配置?Herreman是这个框架的leader,按他的说法:“如果 你需要在应用中保持一定程度的灵活性以便其可以运行在不同的上下文中,或者是你拥有大量的配置,想要集中管理他们,那么我极力推荐使用Prana。因为它 基于Spring,很多开发者已经熟悉了其概念和XML方言”。
Herreman举了一个例子“就我们的情况来说,我们已经创建了一个在线学 习平台,用户可以定制其自己的需求。因为我们自己管理该平台,所以需要有一种机制以允许所有这些定制。如果没有IoC,我们就不得不对每个定制编译不同的 软件版本,或者是我们必须编写一个基于XML或者是数据库的客户配置系统,而对其的维护绝对是一个噩梦。与此相反,我们可以让每种定制都有一个应用上下 文,当应用加载时就去装载该上下文,这取决于登录的用户。更酷的是我们可以从ASP页面(需要从数据库中读取配置)中即时生成应用上下文。”
--- ---
题外话,模式不可滥用,起码我自己不会随便用这玩意。当然在一个庞大的项目面前,如果接口未来会有很多个子类,那么Prana(LoC)将是最好的选择。
上一篇:
AS3.0 设计模式学习-单一职责原则 下一篇:
as3.0轻量级fla组件