原帖地址：http://uh.9ria.com/link.php?url=http://bbs.9ria.com%2Fviewthread.php%3Ftid%3D29919
这个帖子讨论的东西也是我所困惑的。将所有觉得有价值的留言全部记录下来，慢慢消化。
**************************************
也不知道为什么现在会这么多人在用事件。好像是个类就得有个事件。就连我面试个人问个问题都是事件。很多人把解耦就等同于事件。
说两个例子：我面试个人。设计一个功能模块和一个菜单。用户点击菜单模块相应变化。当时他给的答案是往菜单里监听事件。而这确恰恰不对了，这样就变成了模块依赖菜单的。实际上模块完全不应该和菜单有任何关联，而只应该提供一个public function。
还有个例子就是有个包，里面类全部用事件隔离了。但要卸载这个实例时却因为他们穿插了非常多的事件而导致没一个包里的类被释放掉。
使用事件来达到解耦是很肤浅的，你可以看看flash里所有的类。仔细看看它们在什么情况下是public函数，什么情况下是事件。
事件当初是smalltalk在设计一个GUI界面时引入的。因为这样不用去循环监听输入。现在清楚为什么所有的click都是事件。还有冒泡了吧。非常推荐事件的几个地方是：GUI界面响应、异步的调用、通知外部状态更改。
现在说为什么使用事件来达到解耦是非常肤浅的，如果你只知道使用事件来解耦对象。那你真应该好好看看《设计模式》这本书。很经典的一本书。解耦的方法有很多，里面的内层含义都比纯用事件分离类要深刻的多。
**************************************
5# diamondian
你没必要为符不符合我的口味写代码。
这么做的意义在于，使用public那么这个模块是封闭的。也就是说他完全不知道外界，这方便重用。
而把它和菜单隔离是因为这个模块完全没必要依赖或者知道菜单的存在，方便以后菜单可能改变别的交互方式。这是为了以后适应变化。
当然事件是肯定会发出的，因为你肯定会有个click，至于这个事件是在菜单内部处理还是另一个类处理看你自己心情吧。
你可以仔细的去看看flash的内置类，它是什么时候使用属性，什么时候使用方法，什么时候使用事件。
正因为所有在谈所以我觉得有必要发这个贴给大家提个醒。MVC框架你得看它是为什么而提出。网页+逻辑+数据持久化三层结构，方便随时替换掉每一层和每一层都各有专业人才。
一个人牛不牛不是看你是不是用了mvc,事件。而是看你能做出什么出来。看的项目是不是可以适应变化。看看国外的牛人。
flash强项是它可以跑在网页上，第二就是它创造了一种新的交互，可以说没有flash做不出来的界面。
至于其它方面。C/C++/C#那帮人已经走得太远。。。最顶尖的flash程序在C/C++那帮人眼里也都只是小玩意而已。
roxik和动物园在你们眼里应该是神级的人物和作品了吧。这也只是八几年九几年的技术。所以，认真想想我们应该去学什么。
**************************************
楼主确实过于激动了。
第一个模块和菜单例子，简单的应用里面模块可以提供一个public method方便调用。但稍微如果应用复杂些，那么这种方法就不合适了。cairngorm和puremvc提供的mvc方法是用一个controller来监听菜单的点击事件，从而控制模块的行为。
看看flex framework的一些components，为什么设计的MenuBar，TabBar，NavBar都是发布一些状态改变事件，通过监听这些事件达到这些组件的功能，同时也实现了解藕。
当然，事件和解藕并不是必然的关系。事件滥用也是非常可怕的，关键是要用mvc的思想去架构你的application，而不是纯粹为了事件而事件，mvc而mvc。很多东西并不是绝对的。
**************************************
恩，我确实激动了。不过MVC结构在flash是不适合确实需要推敲一下。Java领域流行的东西未必在flash里适合，Flex组件的事件机制你可以参考我说的smalltalk和事件的起源。GUI用事件是非常合适的。
其实相比事件+mvc，我更推荐 ApplicationDomain + 模块化开发+设计模式。你会发现你的程序会在扩展、重用、变化方面更进一步。
看这个帖子：http://bbs.actionscript3.cn/thread-21348-1-1.html
**************************************
我理解这里所说的横向划分即是按功能划分，纵向划分如同之前说的3层结构（显示层，逻辑层，数据层）
灵活使用设计模式是很有好处的，一个东西过了20年还能这么经典肯定会有它的道理。
MVC很适合GUI组件设计和Java三层结构也并不代表就适合flash开发。
偷懒的目的在于适应变化（策划、需求永远是变化的）。如果因为变动一处就让你程序跑不来了那就表明框架有非常大的问题。MVC的目的在于MVC中的任何一层都可以被方便替换（这也是为什么要严格遵循每个子功能都要MVC的原因）
引用个：（我是看不出flash里做纵向划分的好处大于坏处）
Layers架构模式
在收集到用户对软件的要求之后，架构设计就开始了。架构设计一个主要的目的，就是把系统划分成为很多"板块"。划分的方式通常有两种，一种是横向的划分，一种是纵向划分。
横向划分将系统按照商业目的划分。比如一个书店的管理系统可以划分成为进货、销售、库存管理、员工管理等等。
纵向划分则不同，它按照抽象层次的高低，将系统划分成"层"，或叫Layer。比如一个公司的内网管理系统通常可以划分成为下面的几个Layer:
一、网页，也就是用户界面，负责显示数据、接受用户输入；
二、领域层，包括JavaBean或者COM对象、B2B服务等，封装了必要的商业逻辑，负责根据商业逻辑决定显示什么数据、以及如何根据用户输入的数据进行计算；
三、数据库，负责存储数据，按照查询要求提供所存储的数据。
四、操作系统层，比如Windows NT或者Solaris等
五、硬件层，比如SUN E450服务器等
有人把这种Layer叫做Tier，但是Tier多带有物理含义，不同的Tier往往位于不同的计算机上，由网络连接起来，而Layer是纯粹逻辑的概念，与物理划分无关。
Layers架构模式的好处是：
第一、任何一层的变化都可以很好地局限于这一层，而不会影响到其他各层。
第二、更容易容纳新的技术和变化。Layers架构模式容许任何一层变更所使用的技术
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/imlogic/archive/2006/07/28/993554.aspx
**************************************
楼主你说的没错，但菜单的单击是要加监听这应该是公认的作法，这个没什么好说的。
主要是菜单的整个环境相对模块比较单纯，它是很容易独立出去的，即使采用事件模型也不会使程序变得复杂。当然，如果你确信菜单就应该和模块强藕，那你直接调也没什么关系，我们很多时候的确就是这样做的，牺牲扩展性追求开发效率和稳定性，这没什么问题。但这不会影响问题的答案。
我是很讨厌事件模型和MVC框架的，因为我们这是小团体开发，客户端也就3，4个人，而且很多时候都在处理独立模块，本来就没什么相互的干扰，这时候去搞模块间解耦不会有什么实质的好处（因为变化了马上可以同步改），只会让简单的事情复杂化，明明靠代码提示就能出来的一条语句非要去找事件，弄明白参数的对应关系，发出去了还不知道发对没有，麻烦就更不用说了。但就算这样，能分开的还是应该分开为好吧。你一个菜单点击无法就是发个ItemClick事件，所有的菜单都是这样的，约定俗成，大家都知道，为什么不遵守呢？不这样做反而会让人困惑吧？
MVC除了松藕，还有很重要的一部分是使得逻辑清晰。如果C能独立出来当然要独立出来（当然不能独立就别独立出来），这样一旦想去调公用方法，直接去C那找就是了，而不用跑去V里一个一个翻。而那些本来就和显示对象绑死在一起的，正常人首先想到的就是那对象，那就放在对象那让别人调，这种的放在C里和对象对象分开反而找不到。
我对这些东西的概念就是：单纯为了解耦但做了使用会很麻烦，基本不考虑（我们真需要的时候大不了重构），简单就能解耦那咱就做，不做白不做。易用性是第一位的，然后是扩展性，最后是执行效率，但后两者一样要重视。咱们是开发商业产品，不是搞艺术，必须考虑到开发人员的平均水平（真的不高）和成本问题，你做个东西出来大家都不会用那做得再好也没用，虽然可以培训但最后能把时间省出来吗？
最后我必须声明一下，虽然我在这说人少解耦没有必要，但对于开发者来说，只有在你有能够写出解耦的代码的时候，才有资格说“解耦没必要”，不做和不会做是有本质区别的。不管项目要求是什么情况，作为开发者，要想进步就不能有所倦怠，偷懒对自己的发展是没有好处的。等到以后AS发展壮大了，一团队几十号人，不解耦不按规则来那你就混不下去了。
我的概念就是凡是都要有自己的理由，不管干什么都不能盲从。现在AS只是刚刚起步，很多言论都没有经过现实验证，正方反方的都有，没有什么是权威，也没有什么是不变的。所以想少吃亏的话，要靠自己。
**************************************
设计模式有很多种的。并不是只有MVC。
关于那个例子的含义在于：
功能是一个独立的个体。不侦听菜单是因为这样有几个好处：
你可以创建多个这样的功能实例。（如果这个功能可以带参数初始化的话就更多用处了） 这个是为了让重用代码
你的程序不太可能只有一种菜单输入方式。比如按钮，那你是不是也需要侦听这个按钮，如果以后增加鼠标响应方式呢？ 这是为了适应变化
就像UI组件是很适合MVC的。把V分离出来就方便更改组件外观。而VC都完全不用动，但也并不是所有的flash程序都适合MVC
**************************************
MVC不实用于每一个人的思维方式，更不适用于每一个项目。
LZ你的设计思想也跟MVC一样，不能保证万全。
我们做项目讲的是高效，讲的是实现，讲的运行速度以及可维护性。
如果必须缺一，我们也许更愿意折中。
一个Flash project，那开发速度如果慢得跟j2ee一样。你认为最后得来的可维护性有任何意义吗？
换言之，我们会面对随后的更改，但如果完全生搬硬套按照固有的“别人的”思想去开发，那么你的效率会有效的降低~陷入思考的时间会明显的增加。
一个高效的有才的团队，会有一套自己固有的模式。最适合他们的。
我说这些不针对楼主，只是发现现在很多人都太喜欢去追究是否完全面MVC了。提一点自己的浅见
**************************************
- -AS是个很有趣的语言，一方面，它具有Java系语言的特点，另一方面，它又处于JS这种语言的应用范围内。所以，它不能套用以前的任何一个标准。
以前J2EE使用MVC框架，那是理所应当的，因为JS和HTML页面真的很不好管理，MVC一般都是增加效率的，但放在FLASH上就未必。首先FLASH本身就是纯面向对象语言，重用和扩展有很多更好的选择，其次它的应用结构也有很大不同，并不像以前都是HTML平行堆积。更何况，现在企业应用都是用的FLEX，而且通信层都使用了AMF框架，这实际上已经拥有了2层框架，FLEX框架本来就拥有了许多MVC的特征，再往上套用标准MVC框架实际上收益很低。
再加上，这只是前台，后台部分一般也都有一个独立的MVC实现。
我觉得不少使用MVC框架的人都没有发掘出FLEX框架本来的功能，FLEX本来就不是让你到处放Services对象的。也提供了Binding这个简便的观察者模式的实现方式。
滥用框架，这其实是个国际问题，这点中国开发者并没有被特殊化。但这个浪头迟早会转过来的，实践是验证真理的唯一标准，而实践需要时间。
**************************************
**************************************
**************************************