[框架]PureMVC简介

Posted 2022-11-17 ouyangshima

分层

将一个复杂的程序进行层次划分。为每一层进行设计，每层都是内聚的而且只依赖与它的下层。采用标准的架构模式来完成与上层的松散关联。将所有与领域模型相关的代码都集中在一层，并且将它与用户界面层、应用层和基础结构层的代码分离。领域对象可以将重点放在表达领域模型上，不需要关心它们自己的显示、存储和管理应用任务等内容。这样使模型发展得足够丰富和清晰，足以抓住本质的业务知识并实现它。

MVC

MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。

MVC主要把逻辑层和表现层进行了解耦，将一个问题划分成了不同的关注点。增强了应用的稳定性，易修改性和易复用性。

• 视图(View)：就是用户看到并与之交互的界面。它不做数据逻辑方面的工作，通常来说就是显示从模型中获得的数据，或者获取用户的操作。当模型更新时，它需要得知模型已经更新并获取更新后的数据以刷新界面。因此需要在视图处注册关注该模型，以便模型通知视图更新显示。
• 模型(Model)：用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。“模型”有对数据直接访问的权力，例如对数据库的访问。因此它常常也用来与远程服务器作交互，作为一个与外界访问的代理。加载外部资源，如图片，xml等也是在这里操作。模型不关心自己会被如何操作或显示，只要在数据更新时，向关注它的视图发送通知则可。
• 控制器(Controller)：本身不作业务逻辑操作，它负责关联视图和模型，就像一个纽带一样。同时它也负责应用的流程。通常控制器会获得模型和视图的实例，然后调用它们内部的函数。

PureMVC

PureMVC是在基于模型，视图和控制器MVC模式建立的一个轻量级的应用框架，而且是免费的。

PureMVC 结构

PureMVC框架的目标很明确，即把程序分为低耦合的三层：Model、View和
Controller。
降低模块间的耦合性，各模块如何结合在一起工作对于创建易扩展，易维护的应用程序是非常重要的。
在PureMVC实现的经典MVC元设计模式中，这三部分由三个单例模式类管理，分别是Model、View和Controller。三者合称为核心层或核心角色。
PureMVC中还有另外一个单例模式类——Façade，Façade提供了与核心层通信的唯一接口，以简化开发复杂度。

Model 与 Proxy

Model 保存对 Proxy 对象的引用，Proxy 负责操作数据模型，与远程服务通
信存取数据。
这样保证了 Model 层的可移植性。

View 与 Mediator

View 保存对 Mediator 对象的引用 。由 Mediator 对象来操作具体的视图组
件（View Component，例如 Flex 的 DataGrid 组件），包括：添加事件监
听器 ，发送或接收 Notification ，直接改变视图组件的状态。
这样做实现了把视图和控制它的逻辑分离开来。

Controller 与 Command

Controller 保存所有 Command 的映射。Command 类是无状态的，只在需
要时才被创建。
Command 可以获取 Proxy 对象并与之交互，发送 Notification，执行其他
的 Command。经常用于复杂的或系统范围的操作，如应用程序的“启动”和
“关闭”。应用程序的业务逻辑应该在这里实现。

Façade 与 Core

Façade 类应用单例模式，它负责初始化核心层（ Model ， View 和
Controller），并能访问它们的 Public 方法。
这样，在实际的应用中，你只需继承 Façade 类创建一个具体的 Façade 类就
可以实现整个 MVC 模式，并不需要在代码中导入编写 Model，View 和
Controller 类。 Proxy、Mediator 和 Command 就可以通过创建的 Façade 类来相互访问通信。

Notification可以被用来触发Command的执行

Facade 保存了 Command 与 Notification 之间的映射。当 Notification（通知）被发出时，对应的 Command（命令）就会自动地由 Controller 执行。Command 实现复杂的交互，降低 View 和 Model 之间的耦合性。

Mediator发送、声明、接收Notification

当用 View 注册 Mediator 时，Mediator 的 listNotifications 方法会被调用，
以数组形式返回该 Mediator 对象所关心的所有 Notification。
之后，当系统其它角色发出同名的 Notification（通知）时，关心这个通知的
Mediator 都会调用 handleNotification 方法并将 Notification 以参数传递到
方法。

Proxy发送，但不接收Notification

在很多场合下 Proxy 需要发送 Notification（通知），比如：Proxy 从远程服
务接收到数据时，发送 Notification 告诉系统；或当 Proxy 的数据被更新时，
发送 Notification 告诉系统。
如果让 Proxy 也侦听 Notification（通知）会导致它和 View（视图）层、
Controller（控制）层的耦合度太高。
View 和 Controller 必须监听 Proxy 发送的 Notification，因为它们的职责是
通过可视化的界面使用户能与 Proxy 持有的数据交互。
不过对 View 层和 Controller 层的改变不应该影响到 Model 层。
例如，一个后台管理程序和一个面向用户程序可能共用一个 Model 类。如果只
是用例不同，那么 View/Controller 通过传递不同的参数就可以共用相同的
Model 类。

为了解耦合，PureMVC 框架中引入了事件机制，这是个非常简单观察者设计模式，所有的事件都是一个 Notification，不同对象之间通过 Notification 来同步操作和交换信息。例如如果想更新界面中某个 Mediator，首先我们定义 Notification 用于此目的，然后注册 Mediator 监听该 Notification，然后就可以在程序中任何地方生成一个 Notification，通过事件机制，Mediator 就会接收到 Notification，然后更新需要的部分。整个过程 Mediator 只和 Notification 有关，没有其他依赖，有效的降低了对象之间的依赖程度。