为什么要使用像Cairngorm或Mate这样的灵活框架?

简短的回答是:这取决于框架。:)我的想法如下:

flex本身就是一个框架,您可以编写合理的应用程序,而不需要任何额外的框架。Flash有一个允许冒泡事件的内置事件模型,因此您可以在一个深度嵌套的用户界面组件中调度一个事件,并在处理该事件的层次结构中拥有一个更高级别的侦听器。事件处理程序可以委托给您的模型,该模型从服务器中检索数据,而flex的绑定支持可以确保您的视图从模型中得到适当的更新。我认为重要的是要理解,灵活应用程序可以并且应该根据这种方法或多或少地编写,并且任何附加的框架都应该有助于实现这种方法,而不是提供自己的方式来完成最终将您与框架耦合在一起的事情。

也就是说,一个额外的框架,帮助促进这种方法,可以绝对提供价值。我会推荐Mate或Swiz,因为我认为他们实现了这个目标。他们不尝试重新设计轮子或替换flash/flex API的部分,而是对它们进行补充。依赖注入特性使向视图提供数据变得更容易,但不会将它们耦合到任何框架。有许多实用程序可供使用,使远程服务更容易使用。它们还有一个实用程序来帮助测试,甚至在共享对象中持久化数据。

我以前也和凯恩戈姆一起工作过,我不推荐。CG以要求你创建大量的类来遵循特定于CG的API而臭名昭著,并且要求你使用它们的许多单例实现,这些实现使你的应用变得脆弱并且难以单独测试。它基于许多J2EE模式,这些模式至少在5年前就不受Java社区的青睐。

我读过一些关于pureMVC的文章,虽然我不能谈论它的侵入性,但我认为重新设计事件模型(称为“通知”)是愚蠢的,并将您与他们的框架结合起来。当然,你可以说它“隔离”了你的Flash事件模型,以防它发生变化,但我想说pureMVC改变他们的通知模型的几率要比Adobe改变事件模型的几率大得多。:)

如果您曾经尝试过构建一个稍微大一点的应用程序,或者一个非常复杂的应用程序,那么事情很快就会失控。我不知道在我刚开始的时候,有多少项目是因为我不知道模式,或者如何使系统的某些部分在不相互联系或相互依赖的情况下进行通信而获得的。

所以,基本上框架是组合在一起的模式的集合。理论上,如果你学会遵循一个(尝试过的和真实的)框架的“规则”,你的应用程序将不会失控到你发现自己修复了一个错误并导致了两个错误的地步。我去过那里,也不好玩。

我还发现,通过学习使用一个框架,你最初不必太了解你所做工作背后的模式。但不久之后,您就可以很好地处理所使用的模式,并且能够在新的情况下应用它们,或者找到更好的模式。所以它也是一个很好的学习工具。

我相信人们会反对使用框架——这只是我的经验。但是如果您熟悉一些,您可能会发现其中一个适合于一个项目,而不适合另一个项目。

至于flex框架,我个人喜欢pureMVC。老实说,我给凯恩戈姆的唯一一个机会就是。但是我喜欢pureMVC,因为它对我来说是正确的,而且它通常不太依赖于内置的actionscript类。例如,它使用自己的通知系统。因此,如果通知在flex中发生变化,它们仍然可以在pureMVC应用程序中工作。另外,创造者克里夫在他的论坛中也非常有帮助,他对此非常热情。文件也很好。

我建议开发一个超基本的应用程序,在没有任何框架的情况下构建它,然后再与其他几个应用程序一起构建。你不需要完成这个应用程序,只需要了解框架背后的东西。

在以下情况下,您可能会发现使用框架的价值:

• 您在团队环境中工作,希望确保每个人都使用相同的方法
• 你有一个大型的、复杂的应用程序,想要在应用程序的各个部分之间进行有效的通信。
• 您希望能够雇用更多的程序员,并让他们快速高效地工作。
• 您希望确保您的应用程序是用经验证的体系结构构建的
• 您希望充分利用设计模式和解决方案的知识,这些知识是众所周知的
• 您希望简化复杂的应用程序

下面是一篇关于flex框架的好文章。 Flex Framework Comparison

我同意这个结论…Mate是一个很好的灵活框架。

本文中没有提到的另一个有趣的框架是SpiceFactory的 Parsley .

我用 PureMVC (这是一个用于flex的MVC框架)用于我的大型应用程序。像 99英里 说明,这取决于应用程序的大小。

here