Actioncript3设计模式.docVIP

模型/视图/控制器模式M-数据模型。用以存储数据的空间，它与视图和控制器是分离开来的。模型应该不能直接引用视图或者控制器。说白了，就是专门用以存储数据，或者说只保有属性，几乎没有方法（getter、setter除外）。而为了保持良好的封装性，属性均由getter和setter方法来与外界通信。对于数据读写的一些限制或者要求一般会在getter、setter方法里完成。模型(Model)：就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心。目前流行的EJB模型就是一个典型的应用例子，它从应用技术实现的角度对模型做了进一步的划分，以便充分利用现有的组件，但它不能作为应用设计模型的框架。它仅仅告诉你按这种模型设计就可以利用某些技术组件，从而减少了技术上的困难。对一个开发者来说，就可以专注于业务模型的设计。MVC设计模式告诉我们，把应用的模型按一定的规则抽取出来，抽取的层次很重要，这也是判断开发人员是否优秀的设计依据。抽象与具体不能隔得太远，也不能太近。MVC并没有提供模型的设计方法，而只告诉你应该组织管理这些模型，以便于模型的重构和提高重用性。我们可以用对象编程来做比喻，MVC定义了一个顶级类，告诉它的子类你只能做这些，但没法限制你能做这些。这点对编程的开发人员非常重要。 　　业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据 保存（持续化）。比如将一张订单保存到数据库，从数据库获取订单。我们可以将这个模型单独列出，所有有关数据库的操作只限制在该模型中。V-视图。既用户界面系统的显示部分，简单的说，用户看得见的东西均属于视图部分。视图通过调用数据模型来绘制外观，视图通过各种可视的方法把数据呈现与用户。注意，视图仅仅有可视元素组成，但是可以读取模型的数据以所需要的方式呈现。视图(View)代表用户交互界面，对于Web应用来说，可以概括为HTML界面，但有可能为XHTML、XML和 HYPERLINK /albums/739359/739359.html \l 0$0db2c9ca4c3ffc05f31fe71d \o 查看图片 \t _blank ?? MVC模式Applet。随着应用的复杂性和规模性，界面的处理也变得具有挑战性。一个应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型。C-控制器。在需要的时候获取输入（用户交互或者系统通信）以及更新数据和视图信息。控制器主要是用来更新数据以及控制视图位置以及显示与否等（既相当于控制视图的整体，而不控制视图中由数据影响的部分，该部分由数据变化后自行对数据变化做出反应）。控制(Controller)可以理解为从用户接收请求, 将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。例如，用户点击一个连接，控制层接受请求后, 并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应多个模型。mvc是一个复合模式mv，mc都是观察者模式m内部的组件组合模式vc之间是策略模式(可以随时更换不同的控制器)??? 三者的联系。模型应当一直与视图和控制器保持独立。也就是说，模型不关心视图和控制器，模型的数据发生更改将会通过广播的形式通知视图和控制器。视图则一直关心着模型的状态，既时刻侦听模型所发出的事件，并及时更新自己。而控制器也一直关注模型的所有状态，在适当的时候根据用户输入和系统事件来更新模型。控制器和视图是紧密耦合的。视图内部可以完成的逻辑写于视图内部。而对于模型数据的更改，以及视图与视图之间的交互则交与控制器完成。个人认为控制器就像是包裹在一个视图组外面，它控制着这几个视图之间怎么交互，而视图里面又可以嵌套一个这样的结构，一层套一层。就像一个村里，村长管理着这家人干什么，那家人干什么，而这每一家人中的当家又管理着家里的每个人各自应当干什么（控制器控制视图），而所谓视图内部则是指村长不会管你每户人家里是怎么分配完成任务的，而当家的也不会管你个人的吃喝拉撒。而村长和当家都会把一些重要信息，例如账，记到账本里（控制器改变数据），这个账本就像数据模型，都是些数据，它只会告诉人们，现在财务什么状况了，但是它不会管你是