客观地说,Cairngorm对PureMVC的利弊是什么？

为什么在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的邪恶全局变量).