为什么在Flex岩石中使用MVC框架有很多原因，但选择正确的框架似乎很棘手。我对你们实施其中任何一个（或另一个）的经历感兴趣。
萨姆
答案 0 :(得分：13)
The question has already been asked，但是因为你专门询问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的邪恶全局变量。