据我所知,框架减少了常见领域的复杂性,比如登录系统。我在工作中使用Zend MVC,并在ASP.NET框架中做了一些工作,但不了解框架如何帮助客户端开发。在工作中使用Flex的原因是为了单元测试-- ASP.NET框架对此也有帮助吗?
请让我知道为什么我应该或不应该在Flex中使用框架?
发布于 2010-02-14 01:55:44
简单的答案是:这取决于框架。:)我的想法如下:
Flex本身就是一个框架,您可以编写合理的应用程序,而不需要任何额外的框架。Flash具有允许冒泡事件的内置事件模型,因此您可以在深度嵌套的用户界面组件中分派事件,并在处理事件的层次结构中具有较高级别的侦听器。事件处理程序可以委托给您的模型,模型从服务器检索数据,而Flex的绑定支持可以确保从模型适当地更新视图。我认为重要的是要理解,Flex应用程序可以也应该或多或少地按照这种方法编写,任何额外的框架都应该有助于促进这种方法,而不是提供自己的方式来完成最终将您耦合到框架的事情。
话虽如此,一个有助于促进这种方法的额外框架绝对可以提供价值。我推荐Mate或Swiz,因为我认为他们实现了这一目标。它们并不试图重新发明轮子或替换部分Flash / Flex API;相反,它们是对它们的补充。依赖注入特性使得向视图提供数据变得更加容易,但不需要将它们耦合到任何框架。有许多实用程序可以使使用远程服务变得更容易。它们也有一个实用工具来帮助测试甚至持久化共享对象中的数据。
我过去也曾使用过凯恩戈姆,我不推荐它。CG是臭名昭著的,因为它要求您创建大量遵循CG特定app的类,并要求您使用他们的许多Singleton实现,这使得您的应用程序很脆弱,很难单独测试。它基于许多J2EE模式,这些模式至少在5年前就在Java界失宠了。
我读过一些关于PureMVC的文章,虽然我不能谈论它的侵入性,但我认为重新发明事件模型(称为“通知”)是愚蠢的,并将您耦合到他们的框架中。当然,你可以说它将你与Flash事件模型“隔离”,以防它发生变化,但我想说的是,PureMVC改变通知模型的可能性远远大于PureMVC改变事件模型的可能性。:)
发布于 2010-02-13 13:21:29
如果您曾经尝试过构建一个稍微大一点的应用程序,或者一个非常复杂的应用程序,事情可能很快就会失控。我不知道我刚开始的时候放弃了多少项目,因为我不知道模式,也不知道如何让系统的各个部分在不相互联系或相互依赖的情况下进行通信。
因此,从根本上说,框架是一组模式的集合。从理论上讲,如果你学会遵循一个(久经考验的)框架的“规则”,你的应用程序就不会失控,以至于你发现自己修复了一个bug并导致了两个bug。我去过那里,但这并不好玩。
我还发现,通过学习使用框架,你一开始并不需要对你所做的事情背后的模式有太多的了解。但不久之后,您将很好地掌握所使用的模式,并且能够将它们应用于新的情况或找到更好的模式。所以它也是一个很好的学习工具。
我相信人们会反对使用框架--这只是我的经验。但是如果你熟悉其中的几个,你可能会发现其中一个可能适合一个项目,但不适合另一个项目。
至于Flex框架,我个人喜欢PureMVC。老实说,我唯一花了大量时间的另一个是凯恩戈姆。但我喜欢PureMVC,因为它给我的感觉是正确的,而且它通常不太依赖内置的ActionScript类。例如,它使用自己的通知系统。因此,如果通知在Flex中发生变化,它们仍然可以在您的PureMVC应用程序中工作。此外,创建者Cliff在他的论坛上非常乐于助人,他对此真的很有热情。而且文档也很棒。
我建议想出一个超级基础的应用程序,在没有任何框架的情况下构建它,然后再用其他几个框架。你不需要完成这个应用程序,只要感受一下框架背后的东西就行了。
发布于 2010-02-14 02:34:30
在以下情况下,您可能会发现使用框架的价值:
<代码>H111您希望简化复杂的应用程序<代码>H212<代码>F213
这里有一篇关于Flex框架的很棒的文章。Flex Framework Comparison
而且,我同意conclusion...Mate是一个很棒的Flex框架。
本文中没有提到的另一个有趣的框架是Spicefactory的Parsley。
https://stackoverflow.com/questions/2256468
复制相似问题