在Flex岩石中使用MVC框架的原因有很多，但选择正确的框架似乎很棘手。我对我们从实施任何一个(或者另一个)的经验中所获得的想法感兴趣。

山姆

解决方案

这个问题已经被问到了，但是由于我们是专门问Cairngorm和PureMVC的好处的，所以这些是我的想法：

• PureMVC和Cairngorm都很难编写可测试的代码。这主要是由于他们使用全局变量将应用程序代码紧密地绑定在一起，从而很难隔离任何部分进行测试。对于Cairngorm而言，这比PureMVC更为正确，但两者都非常糟糕。
• PureMVC比Cairngorm更具侵入性(这意味着代码在很大程度上依赖于框架，例如，我们必须子类化/实现框架类/接口)，但这并不意味着Cairngorm不是。
• Cairngorm充满了反模式，例如大量使用全局变量，PureMVC隐藏了自身最糟糕的部分。
• PureMVC是抗Flex的，Cairngorm只是没有使用Flex的许多优点。我的意思是说PureMVC重塑了Flex已经拥有的许多东西，因为它希望与平台无关，并且由于其体系结构(尤其是中介者)，使得使用绑定来发挥其全部功能变得更加困难。 Cairngorm只是跳过了事件冒泡之类的事情，而是选择了涉及全局变量的解决方案。

简而言之，Cairngorm是Flex的VisualBasic，它可以工作，但会教给我们很多不良习惯。 PureMVC还不错，它并不是非常适合编写Flex应用程序。

我认为我们应该看的是Mate，它充分利用了Flex的潜力，并且它不是围绕全局变量构建的。相反，它可以编写松散耦合的，可测试的，可重用的和可维护的代码，而无需在其他应用程序框架中看到对框架的沉重和不必要的依赖。

如果我们由于某种原因不喜欢Mate，请尝试Swiz，它比Cairngorm有了很大的改进，但是对于使用全局变量进行中央事件分派仍然有一些怪异的偏爱(考虑到框架的要点之一，这是完全奇怪的选择)是为了避免Cairngorm邪恶的全局变量)。