Flash务实主义(四)――Flash中的MVC

Flash务实主义(四)――Flash中的MVC
2011年04月20日
　　FLASH与传统环境的不同点      MVC最早在1979年的时候第一次被人提出。不过，当时还不存在网络应用的概念。之后当万维网诞生之后，又过了很长时间……
　　它并不是自诞生就开始流行的，而改变的原因很简单――因为两个极其流行的开发框架包含了这种模式，它们就是：Struts 和 Ruby on Rails。之后，模仿者蜂拥而至。所以，在人们眼里看来，实际上是先有的Struts，然后才有的MVC，也无怪乎MVC的概念会始终沾染着Web概念，乃至和一些框架附加内容牵涉不清。
　　因为Struts很好用，别的不说，至少让HTML显得干净了很多。所以很多人都在用Struts，这未必是因为需要MVC模式，而是因为他们需要Struts。因此，当环境变化后，我们不使用Struts而是在使用一些其他的框架的时候，是否还应该像以前那样使用MVC框架就成为了一个问题。因为环境不同，即使在其他语言中使用MVC框架很普遍，也不代表在新环境里同样应该是如此。
　　AS3与传统语言的不同点：
　　AS3是单一语言环境，多层代码混在一起问题没那么严重。AS3正常情况都是一次性编译全部代码，即使用了MVC框架还是需要一起编译。单独编译一个模块减少编译时间有别的办法，不需要依赖MVC。AS3本身的事件和动态特性和一些框架的功能重复。AS3目前的框架还很不成熟，没有提供比较醒目的功能。结果是，至少，目前AS3的MVC框架比起传统语言并没有那么突出的作用，就算用了，也不会像Struts那样有质的变化。而且，至少在我看来，AS3的框架使用成本却不见得比Struts低。两者相减，结果就很麻烦了。
　　而且，AS3在不使用框架的时候有它自己的优势，使用框架会毁掉这些优点：
　　有一个相对还可以的调试器，使用了框架会调试上产生麻烦，主要体现在单步调试步骤变多的问题上。阻碍使用IDE的功能。以Flex Builder为例，你可以通过Ctrl+单击（F4）跳转到指定方法的具体实现，通过搜索引用面板从方法的实现跳转到调用方法的位置。使用框架后，这些功能都会失效。Flex framework相关功能会难以使用，诸如绑定。而且，Flex Builder支持拖拽式的将数据接口绑定到视图的功能，可以部分实现零代码编程，框架也会阻碍这个过程。       此外，企业应用和网站还好说，游戏还有另一种情况。游戏的结构并不同于原来的专门用于呈现数据的结构，可能也就是其中的用户界面(User Interface)部分和以前的结构比较类似，其他的诸如地图，诸如人物，无论怎么想也无法套用MVC框架，首先从效率上就说不过去。举个例子，一个项目有3个客户端人员在开发，一个在做地图，一个在做战斗，一个在做UI。前两者都和MVC没什么关系，结果只有一个人在用MVC框架开发界面……而且，开发前两者的时候，开发以及协作难度其实是比开发界面要高的，既然他们都搞定了，为什么开发界面的人还必须靠框架辅助才能解决这个问题？
　　这使得FLASH比起一般的情况，会更加不适合使用MVC框架。
　　不使用现有框架并非无法实现MVC        既然我在说框架不好用。那么不用框架，我们又该怎么做呢？
　　实际上，如果你只是想实现单纯的模型―视图―控制器(Model View Controller)分工职守，它只是一个架构模式而已。将模型和视图的代码分开，并提出控制器的代码，然后互相调用各自方法就算完事了。Model的全部引用放在固定的位置，View的引用使用静态属性储存或者用管理类管理，Command可以作为函数或者类直接初始化并执行，亦可以通过反射。这并不需要专门的工具类来辅助，附加成本也比较小，自然就可以适用于任何规模的项目。
　　当然，你可以实现一个简单的通信框架，提供必要的功能，如果你需要的话。这和使用一些专门的MVC框架需要的成本是完全不同的。
　　然而，我的意见则是――MVC是非常好的架构模式，不管什么样的项目都建议尝试使用，但是用框架的话，请务必谨慎。
　　关于最简的MVC，最近看到一个让人很