我希望我的mxml或actionscript组件是可重用的，并且是松散耦合的。我想知道使用FlexGlobals.topApplication来调度和侦听事件是否是一种好的做法。例如，我希望我的登录组件将事件调度到topApplication，这样当我在不同的项目中重用该组件时，我就不必更改任何内容，因为所有应用程序都有一个topApplication
我的另一个选择是有一个单独的静态类来处理事件调度，但随后我将创建对该静态类的依赖关系。如有任何建议，我们将不胜感激。谢谢
我建议您阅读事件传播的相关知识，并让登录组件在事件在层次结构中冒泡时将其发送给"任何人"。
http://livedocs.adobe.com/flex/3/html/help.html?content=events_08.html
我在很大程度上同意Stian的回答。关于weltraumpirat的评论，我觉得依赖注入可能很好，但也会在调试/测试IMO方面增加很多复杂性，如果你实际上不打算有不同的接口实现，只会添加很多垃圾代码来查看，而没有任何实际好处。我觉得Spring在服务层方面运行得很好，因为如果您切换数据库或类似性质的东西，您可以更改数据访问层（DAO）的实现，但我很难看到前端的好处。
我不建议使用topLevelApplication，因为你最终会得到像cairngorm这样的东西，在那里你有一组在顶级发生的巨大事件/事件处理程序。更不用说，如果你遵循他们建议的模型，你最终会得到一堆毫无意义的事件类，它们只是定义了一个字符串（使用Cairngorm有更好和更糟糕的方法，但我不喜欢我在野外看到的）。
我公司的一位开发人员编写了一个自定义MVC"微框架"，它非常适合我们，我们可以将控制器连接到任何显示对象，为其处理事件，这非常有效，但确实需要开发/测试它的初始开销。它是在Flex中现有Event方案的基础上构建的，因此我们的MVCEvent类扩展了Event（我们的默认情况下只是冒泡，因为我们倾向于将其用于我们正在创建的事件类型，其中控制器可以位于UIComponent调度事件之上的任何级别，并且可以始终选择关闭冒泡，但是从event基类开始意味着我们可以使用内置的EventDispatchEvent（）方法）。他写的几乎所有东西都使用接口来定义每个部分的方法，并且只假设对象实现了在特定上下文中使用的给定接口（如IMVCEvent、IMVCCommand）。如果内置框架实现不适用于您的特定场景，您只需要创建一个实现相同接口的新类（如果扩展也不适用于您的情况）。这提供了巨大的灵活性，但同时我们通常能够重用事件、命令或控制器的现有实现。在每个应用程序中，我们只是为特定于应用程序业务规则的内容定义新的视图和命令。
所以，归根结底，我建议你把自己的库作为一个库，然后在你的许多项目中重复使用这个库。您将了解自己的库的内部和外部，并可以根据自己的需要快速调整它，而无需试图理解某人设计的MVC框架要处理的许多用例。
我意识到就现在完成任务的速度而言，这不是一个理想的解决方案，但我认为这确实是长期的最佳解决方案（这对我们来说很好，这就是我所能说的）。
在这里进行修改，以承认现有的Flex MVC框架可用，并安抚人群。
机器人腿顺便看看机器人腿的创造者对使用他的代码有什么看法：他的话不是我的
Swiz
Mate
关于flex框架的堆栈溢出问题