AS3中的MVC框架解读

真不想讨论这个问题。MVC，TDD一类，是被炒作过的概念，实际上已经具有了特殊性，并不能用普通的方式来验证它的正误。专家说它好未必真好，因为那是专家，有人说他好未必真好，因为可能已经被洗脑了。本来嘛，只要是个东西，就肯定有支持派和反对派，但是在炒作氛围内，反对派的声音是听不到的。

所以这种时候，能够相信的只有自己。

以下也是我个人的看法，同意或者不同意，悉听尊便。


什么是MVC？


不知道从什么时候起，这个问题变成了一个与“一万人眼里有一万个哈姆雷特” 类似的命题。可能是因为嘴仗太多而没有结果，最终妥协成了这个样子吧。MVC只是一个词，在这个词下可以涵盖各种意义，事到如今，谁知道它最初的意思是什么？按字面意思， MVC就是(Model View Controller)模型－视图－控制器，是一个设计模式（也可以称为架构模式），但目前在大部分人眼里显然并不只有这点意义。受到各种MVC框架的影响，消息通信，依赖注入，隔离编译等等概念现在都加入到了MVC的概念里，而且因为应用上的重叠和相似性，还常常和三层架构的概念混淆。

一个名词的意义，是由人们的理解来决定的。既然有那么多人认为必须发布消息，必须通过反射获取实例，模型修改必须更新到试图才能算MVC，那MVC就是这样的东西。但这样就几乎无法讨论了。因此这里我就返璞归真一下，从最基本的概念入手，或者还能稍微说出点名堂。


对于一个用于显示的程序，最开始，只有View（视图）。

我们要获得一个数据并显示，就是写段代码调用接口，获得数据，然后根据数据更新视图。而这里的数据只是一个临时变量，或者存在于视图的某个属性中。显然，这样做的话，数据是依赖于视图的，如果不通过视图，或者视图根本不存在的时候，其他模块就访问不到这个已经返回的数据，则需要重新调用一次，这显然是一种浪费，而且也不便利。因此我们在这里将数据保存到别处，和视图不共享同一生命周期，那么这分离出来的数据则被规定为Model（模型）

（在这里我必须打断说明下，模型!=数据，仅仅是在这个简化例子里模型==数据。模型是为视图提供内容的单独模块，具体内部是什么情况则是各种各样的，提供数据只是它的功能之一）

至此，就是最基本的分离表现层的原则。然而，有个地方却是分不开的——原来控制加载数据的这部分代码。它负责的是获取数据，并指示视图根据数据更新的任务，而它的去向有两个选择：要不加到视图上（这是通常的做法），要不加在模型上（如果需要模型对应多个视图），反正他不可能因为分离就凭空消失。那么我们把这部分代码提出来作为单独的部分，就是Controller（控制器）

一旦分离出了控制器，联系模型和视图的具体代码就不再处于两者之上（当然调用代码还是有的），而是一个独立的部分。它有自己的名字，而且不会和其他不相关的内容混合在一起，非常清晰，容易定位。而模型和视图从此也只关心控制器，而不关心对方。他们的代码都是处理自己的事情，别人的事情全部交给控制器去办，这使得他们自己的功能也非常独立，减少了需要考虑的要素。

这只是代码位置的移动，但是这样移动后，将牵涉内容最多最易变，但是代码量最少的代码单独放入控制器中，并妥善管理。相当与将分散在房间各处的开关集中于一处，排列整齐并标注名字，做成遥控器在手里把玩，从此就能从奔波于房间各个位置，寻找隐藏在角落里的小突起的日常活动中解放出来。其意义，不言而喻。

而这，作为MVC的作用，已经足够了。


MVC框架


一旦我们将视图，模型，控制器分离后，可以做到什么呢？

因为视图和模型都只用处理自己的事情，对控制器的调用只是一句代码而已，那么，它们实际上就可以被隔离出去。负责这部分代码的人只需要关心自己的事情，而不需要关心整个环境。同样的，编写控制器的人只需要知道视图和模型的对外接口，而不需要了解它们的具体实现，也就是只需要关心环境。这使得不同开发者需要的知识被分隔开，每人只需要了解有限的少量知识，最终却又能顺利合并在一起。

这是就是协作分工的基础。

在这之后，三者的关系只存在简单的调用代码。那么为了能够彻底的分离和解耦，就可以将调用代码改为发送消息或者其他的动态形式，这样就能在没有其他部分的时候独立编译。由不同人在不同的工作环境独立完成自己的部分，并在最后发布时候简单合并在一起，这确实是最理想的协作模式。

做到这点需要一个消息框架，而这就是MVC框架的主要任务。除此之外，各种不同的框架还会加入其它设计模式，提供各种附加功能，自动依赖注入就是其中一项。还可能加入其它的中间件，进一步分割层次，诸如分离出视图其中的逻辑部分，使得绘图和位置代码不会和逻辑代码混合，方便分工以及修改。使用观察者模式，使得数据部分的修改可以自动同步到视图上，如此这般……MVC框架指的是“实现MVC的框架”，而非“只实现MVC的框架”，仅仅实现MVC，这个框架的功能太过贫乏了，毕竟MVC也就是那种程度的东西。

最终，完成了这些之后，就成为了一般人表面看到的东西。虽然各式各样，我们都将其称之为“MVC框架”。

命名怎么都可以，实现的功能才是唯一重要的。


MVC并不是3-Tier（三层架构）


在这里必须插入做一个补充说明，如果不将MVC和三层架构的关系说清楚，后面将会产生大量误解。

这两个东西只是听起来各个部分的名字比较像而已，MVC是视图-控制器-模型，三层架构是表现-业务-数据访问，此外没有任何相似之处。实际上就是完全不同的两个东西。但是因为用了MVC的架构往往也实现了三层架构，所以不少人以为前者已经包含了后者，实际上完全没这回事。

我们可以认为，三层架构的逻辑层和数据层代表了MVC中的模型，也可以认为MVC架构是三层架构中的表现层部分。实际上，MVC一直都被称为表现层架构。

所以不要再把什么“表现层和业务层分离，容易更换服务端语言，数据库这类东西”放在MVC头上来了，尽管它听起来和“视图和模型分离，容易更换服务接口”差不多，实际上一点关系都没有。

不少flasher认为服务端已经用了框架，FLASH部分作为视图没有必要自己在内部重复实现一次MVC，也是基于这个误解。FLASH部分处于三层架构的表现层，而不是MVC中的视图。既然使用了FLASH替换了原本的HTML/JS部分，服务端原来的MVC部分的内容也自然也无法实现（被替换了），只剩下业务和数据访问层。因此这是完全不相冲的。

MVC属于表现层架构，而表现层的任务是将数据呈现出来，所有交互也都是为了呈现数据。虽说并不是只能呈现数据，但它的确是因此而生的。


MVC框架的优点与缺点


关于优点，上面也说了一些，基本上就是：

l 结构清晰，定位迅速

l 控制器可方便地插接

l 各部分皆可独立移植，替换

l 模块职责明确，利于工程化管理

l 容易进行单元测试


然后缺点都是这么说的：

l 较复杂，难实施

l 类多，代码多，工作量会增加

l 稍微有点慢

l 不利于整体调试

l 一般情况无法获得IDE的辅助


我对于通信框架的观点


关于这个，我稍微有点自己的想法，但是抱歉的是，说的是反面意见。毕竟MVC的正面观点已经被说到不用说的程度了，我也不想再复述一遍了。而这个意见，也是直指目前MVC最重要的一个部分——通信框架。

现在的MVC框架有一个共有的特征，一定会通过消息通信来解耦，使得三部分内容可以隔离开。这看起来很理想，但是实现解耦本身这个行为就是有成本的。现在的消息解耦都是通过添加共同的第三者来完成的，而现在这个第三者就是标示他们的字符串。而且，不同的框架，还会有各种不同的中间者，而这些中间环节越多，出错的几率自然也就越高，要知道，这些中间者都是编译期间（甚至运行期间）都不会产生错误的。而且缺乏IDE辅助，你在阅读别人代码，包括编写自己代码时都会有一定困难，由于调用关系复杂，在各个模块中转换多次跳转会浪费时间。而修改时，由于不会产生错误，也可能无意破坏模块之间的联系，另一方却毫不知情。

因此，需要更完善的制度来弥补这个缺陷，比如更加详细的文档，更严格的版本控制，更标准的开发流程。甚至于，最好严格执行单元测试，因为即使是修改时简单的拼写错误都会导致未知的问题发生。总之，需要开发者更多的精力，更多的开发成本，和它们相比，写的代码数量多点都是小事了。于是乎，MVC框架未必总是能提高开发效率。它的主要作用是使你的开发过程条理化清晰化，使多人开发时能更好的并行操作，避免因此大幅降低效率。但如果你不用它一样可以条理化清晰化，并行开发用SVN/GIT就能简单完成，那么使用它得到的好处就非常有限，成本提高将无法忽略。

所以才会说，MVC框架不适合小型项目乃至部分中型项目，因为他们即使不依赖MVC框架的这些特性依然可以做的很好，一样可以分割模块制定接口，即使有部分分工重叠，因为人数少，也可以用SVN进行妥善管理。

此外，还有很重要的一点：理想和现实是有距离的。如果你的开发人员都非常优秀，可以正确使用MVC框架，在适当的情况下，的确可以利用到它所带来的好处。但是如果不是这样呢？MVC框架一般都只提供了功能，而没有限制你使用功能。你同样可以将模型需要的逻辑写在视图里，将本该放在Command中的逻辑放在其他的地方，以及实现各种古怪的写法，然后机械地套用一遍框架，这样一来，不仅必须承担框架带来的不便，还一点好处都得不到。所以，必须对人员进行培训，对培训也没用的人进行筛选，这又是不小的一笔成本。

更糟糕的是，使用MVC框架的团队未必能够意识到这些。他们可能没有文档，不进行版本控制，没有制定开发流程，甚至，他们找来进行MVC方面培训的人，培训的内容是完全错误的。

MVC框架并不是平民可以玩的东西，它本来就是为大型项目设计的。对于大型项目，人员，制度，管理，流程，这些都不是问题，有问题的是项目规模大所导致的混乱。于是乎，上面说的缺点，都不再是缺点。

中小型项目，真不好说。

但是，如果MVC框架不实现消息通信，也就是不对三部分实现完全的解耦的话，那就是另一回事了，上面出现的问题其实主要都是通信框架的问题，而不是MVC本身分层的问题。不过，因为所有的MVC框架都实现了消息通信，所以，如果你想避免上面的问题，就只能自己开发MVC框架。而这也是现在很多游戏团队实际在做的。


FLASH与传统环境的不同点


MVC最早在1979年的时候第一次被人提出。不过，当时还不存在网络应用的概念。之后当万维网诞生之后，又过了很长时间……

它并不是自诞生就开始流行的，而改变的原因很简单——因为两个极其流行的开发框架包含了这种模式，它们就是：Struts 和 Ruby on Rails。之后，模仿者蜂拥而至。所以，在人们眼里看来，实际上是先有的Struts，然后才有的MVC，也无怪乎MVC的概念会始终沾染着Web概念，乃至和一些框架附加内容牵涉不清。

因为Struts很好用，别的不说，至少让HTML显得干净了很多。所以很多人都在用Struts，这未必是因为需要MVC模式，而是因为他们需要Struts。因此，当环境变化后，我们不使用Struts而是在使用一些其他的框架的时候，是否还应该像以前那样使用MVC框架就成为了一个问题。因为环境不同，即使在其他语言中使用MVC框架很普遍，也不代表在新环境里同样应该是如此。

AS3与传统语言的不同点：

l AS3是单一语言环境，多层代码混在一起问题没那么严重。

l AS3正常情况都是一次性编译全部代码，即使用了MVC框架还是需要一起编译。单独编译一个模块减少编译时间有别的办法，不需要依赖MVC。

l AS3本身的事件和动态特性和一些框架的功能重复。

l AS3目前的框架还很不成熟，没有提供比较醒目的功能。


结果是，至少，目前AS3的MVC框架比起传统语言并没有那么突出的作用，就算用了，也不会像Struts那样有质的变化。而且，至少在我看来，AS3的框架使用成本却不见得比Struts低。两者相减，结果就很麻烦了。

而且，AS3在不使用框架的时候有它自己的优势，使用框架会毁掉这些优点：

l 有一个相对还可以的调试器，使用了框架会在调试上产生麻烦，主要体现在单步调试步骤变多的问题上。

l 阻碍使用IDE的功能。以Flex Builder为例，你可以通过Ctrl+单击（F4）跳转到指定方法的具体实现，通过搜索引用面板从方法的实现跳转到调用方法的位置。使用框架后，这些功能都会失效。

l Flex framework相关功能会难以使用，诸如绑定。而且，Flex Builder支持拖拽式的将数据接口绑定到视图的功能，可以部分实现零代码编程，框架也会阻碍这个过程。


此外，企业应用和网站还好说，游戏还有另一种情况。游戏的结构并不同于原来的专门用于呈现数据的结构，可能也就是其中的用户界面(User Interface)部分和以前的结构比较类似，其他的诸如地图，诸如人物，无论怎么想也无法套用MVC框架，首先从效率上就说不过去。举个例子，一个项目有3个客户端人员在开发，一个在做地图，一个在做战斗，一个在做UI。前两者都和MVC没什么关系，结果只有一个人在用MVC框架开发界面……而且，开发前两者的时候，开发以及协作难度其实是比开发界面要高的，既然他们都搞定了，为什么开发界面的人还必须靠框架辅助才能解决这个问题？

当然，对于一些UI开发人员很多的团队，的确有那么点意义。但是在游戏开发团队里，这类人员的人数至少会比以往更低。如果其他人都是商量好接口并按功能模块分工，为什么UI就不可以呢？

这使得FLASH比起一般的情况，会更加不适合使用MVC框架。


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


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

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

觉得MVC框架好用，提高效率，是否有平行对比的例子？你怎么就知道是使用了框架的功劳，而不是规范了代码结构，制定了新的协作流程，甚至是开发人员水平提高的功劳？怎么知道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%以上的内容。


就算是使用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。

这些规则实际上是很明确的，是完全可以预知的。就算预知错误，也是很容易修正的。

解耦是手段，而不是目的。盲目的最求“无”耦合，只会让自己的程序变成一盘散沙。正是适量的耦合，程序才能拥有一个确定的形态，才不会变成史莱姆。


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

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


普遍误解


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

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


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

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

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

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


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

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

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


l 是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应该是没有任何与通信相关的，也就是会向外的逻辑的。

最后

以上就是孤独白猫为你收集整理的AS3中的MVC框架解读的全部内容，希望文章能够帮你解决AS3中的MVC框架解读所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。