Flash务实主义（四）——Flash中的MVC

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，最近看到一个让人很囧的例子。不过这个例子对大家理解MVC是有帮助的。

这玩意的确……基本算是MVC，只差一点而已。MVC是架构模式，至少结构上要分开，即使不分文件至少要让能看得出来谁是谁（原文可没有红字），所以只需要把这些代码分成三个文件，那就可以称得上是最简的MVC了。

这是我在他的下面补充的代码。

结果是，View只关心与自己相关的Model和Command，Command只关心与自己相关的View和Model，Model谁都不关心， 这和一般情况需要的解耦目标是一致的。虽然这样并不算完全解耦，但是至少在思路和逻辑分离上是做到了，仅仅是协作方面存在问题，比如无法实现自由的并行开 发，而这个加入简单的反射也可以解决。

所以，单纯的MVC并不困难，没什么要不要放弃一说。还有就是上面只是极端例子，但就算是这种东西，比起完全不实现MVC，也至少实现了50%以上的内容。

是否使用框架应当理性对待

程序员都是理科生，应当用理科生的思考方式（当然我并没有让你们都去模仿Sheldon）。在使用MVC框架的过程中，不管是觉得好，还是差，都要考虑清楚问题的源头在哪。

觉得MVC框架不好用，降低效率，是否曾经有过平行对比的例子，你能否确认不用它效率就确实能提高？效率低有没有可能是框架之外的原因？

觉得MVC框架好用，提高效率，是否有平行对比的例子？你怎么就知道是使用了框架的功劳，而不是规范了代码结构，制定了新的协作流程，甚至是开发人员水平提高的功劳？怎么知道MVC框架并没有起了反效果？

使用了框架，看到了结果，然后根据结果的好话直接判定框架的好坏，这太武断了，作为一个理科生，我们绝对不能这样做。至于那类连比较都没有，而是以“我用了框架，项目依然完成了，没有因为用了框架而失败”这种理由来支持使用某个框架的人，我无言以对。

推荐MVC框架

我并没有完全反对使用MVC框架。这要看你的项目类型，规模，人数。满足条件的时候当然可以使用。尤其是在企业应用里，如果你有幸出现六个客户端的话，没MVC框架可能还真是会出问题。

pureMVC和Cairngorm 是两个较早出现的框架，目前我不建议再使用它们。pureMVC的问题在于过于强调分离而缺乏实际功能，提供的便利很难抵消它本身的消耗，性价比较低。Cairngorm 的问题则在于过于强调模型更新视图的流程，限制太多，灵活程度不够。

后出的几个框架就好多了，Mate使用了一个全局事件定义，配合FLEX写法非常简略。Swiz则是用控制反转+依赖注入，也就是Spring的做法，而且元标签注入的方式很有趣，感兴趣的可自行查阅资料。

我这里要说的是Robotlegs。这是一个和Swiz非常相似的框架，但也有一些自己的特点。首先它是基于pureMVC的，你依然可以像 pureMVC这样来使用它，对于相信pureMVC的团队它是很容易接受的代替品。他让pureMVC也同样拥有了控制反转和依赖注入，包装了大部分功 能，配置代码大大减少，而且不管用不用FLEX framework都可以很自然地使用它。

Robotlegs的教程可以看这里：

http://wenku.baidu.com/view/42a08b235901020207409c60.html

但我得提醒大家，虽然我觉得Robotlegs很便利以及有趣，但是并没有在项目里使用它，因为我的项目规模不大，而且是游戏。实际上，我甚至自己 实现了一个依赖注入框架，可以很简单的加入到现在的项目中，成本几乎为零，却依然没有去用。使用一个东西要看是否需要去用，而不是可以用就用，更不是“因 为用了没有遇到问题所以就用”。用一个东西必须有收益才可以，尤其是在明明看到有损失的时候。仅仅是用“看起来更正规”这类自我满足的理由来决定自己的行 为，太愚蠢了。

当然，如果你需要它，那就应该毫不犹豫的使用。不要受到抱怨框架的人影响，他们大部分都有自己的问题，提出的理由也未必是正确的，你并不一定会赴他们后尘——前提是你真的需要它，而且，要将使用框架需要的条件全部补齐。

就算是使用MVC框架也不需要完全解耦

解耦是一个扩展性要求，但扩展性要求并不是越多越好的。

这是一个普遍的误区。诸如使用pureMVC的人，很多都纠结于完全的解耦，以至于用了Command，在Command中改变View的时候还是必须要发一遍Notification。

Command这种类，一般都是在相关的View，Model完成后才开始编写的。比如普通的 StartupCommand，OpenWindowCommand，没有对象又如何编写？它在编写顺序上应该是，就算不是也是可以放在View和 Model之后的。那么在协作关系上，他就可以直接访问所有相关类，不需要为了这种原因而解耦。

虽然pureMVC将消息全局化了，但是消息实际上是分局部和全局的。比如一个Proxy发生变化要求所有监听某个消息的View更新，那么当然应 该发一个叫做I_AM_CHANGED的Notification，并由不同的View来监听这个消息并更新，这个就应该是全局消息。但有些消息就是局部 的，是一对一的，比如一个叫做SEND_DATA_TO_WINDOW1的消息，按它的字面意思就应该是刷新WINDOW1，那么由它来触发的 Command，就应该直接耦合 WINDOW1这个View来设置值，而不是再发个类似REFRESH_WINDOW1的消息，因为SEND_DATA_TO_WINDOW1的名字已经 确定是针对这个View了，如果最终它却没有操作这个View，那才是有问题的吧？

解耦归解藕，但是对于已经有了意义上的联系的模块，结果却不耦合，在任何时候都是没有意义的。即使需求变化，逻辑变化了，使得 SEND_DATA_TO_WINDOW1最终不是改变WINDOW1的数据，而是WINDOW2的数据，那么这个Command连带相关 Notification的名字就必须修改，也就是说，意义上的紧密联系，在实际操作上和耦合了是一回事。既然已经是这样了，再做成不耦合，给自己制造麻 烦的又有什么意义呢？

除了上面的情况，我们也要考虑，真的有必要将项目拆得那么细致么，有没有必要为了1%以下的可能性来解耦两个相关性很强的部分？比如一个叫做 ShopPanel的View和一个叫做ShopModel的Model，到底在什么情况下，ShopPanel会不去调用ShopModel，而是别的 东西？而且Panel上可能还有各种文字，使得自己意义上只能调用商店的数据。真是要调别的东西，应该重新制作一个新的View吧？而且别忘了 pureMVC是可以多个Mediator套用一个View的。这种情况下，我们直接在Mediator中耦合ShopModel，有什么不可以的？当 然，反过来，ShopModel被多个View调用的情况很普遍，所以我们不能让它来耦合ShopPanel。这些规则实际上是很明确的，是完全可以预知 的。就算预知错误，也是很容易修正的。

解耦是手段，而不是目的。盲目的最求扩展性，只会让自己的程序变成一盘散沙。正是适量的耦合，程序才能拥有一个确定的形态，才不会让人感到茫然。

普遍误解

其实现在使用框架的人群里，真的能够发挥框架长处的确实比较少，尤其是在水平层次较低的Action Script开发人员之中。一方面，这污染了框架的名声，同时也是不建议使用框架的理由之一，因为人员水平限制也是实际项目中不可回避的现实问题。

如果你决定使用MVC框架，就必须提高自己的认识。我拣几个最常见的问题来说吧。

• 并不是用了消息通信就算用了MVC

消息通信只是一个手段，只使用框架的通信功能在View之间发送消息的话，而将其他功能全部抛弃的话，直接使用事件更好，那还套一个MVC框架就是在没事找事了。

MVC关键还是在于代码逻辑的分配，通信只是个附赠品而已。要了附赠品而扔了原来的商品——咱们买的不是小浣熊干脆面，对吧。

但是如果你的目的就是赠品，其实也没什么。比如你就是想用的这个通信框架来发发消息，就不打算用它的MVC，又或者MVC部分是自己实现的。那么我还是建议你把消息部分干脆也自己实现了，别人的始终没有自己的好。

• 既然用了MVC框架，就不要图省事

要清楚，松散耦合不仅仅是一个形式，目的在于减少模块间的联系。因此，如果你一方面在解除两个模块之间的耦合，一方面自己又没头没脑的将其他模块的内容耦合进来，就会使得你的行为变得没有意义。

现在一些人一方面在硬套框架，一方面又图省事而随意引入其他类，就属于这样的行为。那些类是可以引入，但你这样做，框架本身的意义就没有了。要不你就不用框架，要不就别这样干，这里只能二选一。

• 是Mediator知道View的一切，View完全不知道Mediator，而不是相反

对于使用pureMVC的同僚们，我真是不明白你们到底是怎么把这个反过来理解成“View知道Mediator的一切，而 Mediator完全不知道View”的，因为官方实例上写的很明白。估计是把mediator当成通信专用的模块类了吧。但是如果你放弃了 mediator分离View代码的特性，只是用来通信的话，至少要保留原来的通信功能，就是让Mediator依然可以直接访问View。否则既然 Mediator是用来通信的，它却不能操作View，结果还得设法和View再通信一次……

pureMVC要求“View完全不知道Mediator”是为了能够在不修改View的情况下更换Mediator，但这种需求并不多 （多的是在Mediator不变的情况更换View，这个需要用接口或者条件判断解决），所以可以放宽点让他们互相引用，这样两者通信都能畅通。

pureMVC实现“View完全不知道Mediator”的方法是用Mediator直接去监听View的某个组件的鼠标事件。这只需要监听一次，也不需要传递消息。Mediator存在的期间，按pureMVC的标准View应该是没有任何监听逻辑的。

扩展阅读

http://baike.baidu.com/view/31.htm

http://www.360doc.com/content/09/0804/08/163747_4655702.shtml

http://hi.baidu.com/5%B1%CF%D2%B5%D2%D4%BA%F3/blog/item/2a018366a08e54cde6113af7.html

http://hi.baidu.com/lwcandwo/blog/item/8fb4b3036d01eb8ad43f7cf4.html

http://developer.51cto.com/art/200904/120649.htm