常用Flex IOC框架比较分析

核心提示： 图片看不清楚？请点击这里查看原图（大图），图2. 引入IOC后的框架接下来，常用Flex IOC框架比较分析(4)，我主要说明通过引入IOC，应用中可得到改善的部分，它也会给你的类带入本不需要的杂质，如果你能只实例化需要的对象，对象查找 用户登录成功后，应用取回两个对象

图片看不清楚？请点击这里查看原图（大图）。

图2. 引入IOC后的框架

接下来，我主要说明通过引入IOC，应用中可得到改善的部分。

对象查找

用户登录成功后，应用取回两个对象。这两个对象包含的信息会在不同的视图中展示给用户。当准备仪表盘的表现层模型（DashboardPM）时，我需查找这两个对象实例：

在MainPM中：

public　function　set
authenticated(　value　:　Boolean　)　:　void
{
//..
var　locator　:　ModelLocator　=　ModelLocator.getInstance();
dashboardPM　=　new　DashboardPM(　locator.user,　locator.friends　);
//..
}

ModelLocator使用了单例模式，用于存储模型对象。依靠单例，我在应用的任何地方得到都是相同的对象实例，因为仅仅创建一个对象实例。在这种情况下，我可以安全访问User和Friends，因为在任何地方，它们都只有一个实例。

不过，单例也有其不足，比如造成单元测试困难——在测试套件整个存在期内，你都必须关注对象的生命周期。因为单例独立于测试用例，静态存储而不会被当做垃圾收集。

对象传递

弱化应用中单例负面影响的办法之一，是按类的继承层次传递对象。

你可以在DashboardPM的构造器的实现中看到这一点。它需取得User和Friends模型，然后由表现层模型将这些实例传递给自己的子类（尽管实际上只会用到User对象）。一个对象依赖于另一个实际并不直接使用的对象，这显然是一种糟糕的设计实践。

对于小的例子程序而言，这不会是什么大问题，但随着应用规模的扩张，你可以想象这种方法会带来多大的工作量。它也会给你的类带入本不需要的杂质。如果你能只实例化需要的对象，代码将变得更为干净。