查看评论 PureMVC框架的目标很明确，即把程序分为低耦合的三层：Model、View和Controller。它们合称为PureMVC框架的核心，由Facade统一管理。关于它的核心层，我们不需要管太多，只需要记得下面几点就可以了： 一、Model保存对Proxy对象的引用，Proxy负责*作数据模型，与远程服务通信存取数据。 二、View保存对Mediator对象的引用。由Mediator对象来*作具体的视图组件（View Component，例如Flex的DataGrid组件），包括：添加事件监听器，发送或接收Notification ，直接改变视图组件的状态。 三、Controller保存所有Command的映射。Command可以获取Proxy对象并与之交互，通过发送Notification来执行其他的Command。 上面的什么对什么的引用，可以一开始看的时候很难理解，我们暂时不用管它谁对谁的引用的。这些已经由框架为我们管理好了，我们要所要做的是编写具体的Command，Mediator，Proxy。 一、Proxy是负责*作数据模型的，什么是数据模型？数据模型就是数据库，XML等等。我们可以直观地理解为，Proxy是用来对数据模型进行查询、插入、更新、删除等*作的类。*作完成后，它就会发送Notification，也就是通知，告诉其它两个层我已经完成工作了。 二、Mediator负责*作具体的视图组件，包括：添加事件监听器，发送或接收Notification ，直接改变视图组件的状态。好像抽象了点。具体的说吧，Mediator是负责管理用户界面，与用户进行交互*作的。如：给Button添加事件，当用户点击按钮时，发送Notification，告诉Controler我们执行什么样的*作。比如这是一个登录的按钮，那么Mediator就会告诉发送通知给Controler，告诉它要执行登录*作。此外，Mediator还负责直接改变视图的状态。就像，我点击了登录按钮后，Mediator就改变它，让登录按钮不过用，避免重复*作。它还可以在视图上显示一条信息，告诉我正在执行登录*作。总的来说，Mediator是用来管理视图的。 三、Command可以获取Proxy对象并与之交互，通过发送Notification来执行其他的Command。再拿上面的登录例子作解释，当点击了登录按钮后，Mediator就会告诉Controler要执行相应的Command了，比如LoginComand。既然是登录，那么还得要知道用户的信息才行。Command就会发送Notification告知Proxy，我需要某个用户的信息。那么Proxy就会访问数据库（也可以是别的数据模型），查询对应的用户信息，然后发送Notification通知Command我已经查询好了，差把信息返回给Command进行验证，与些同时，Mediator也可以接收Proxy发送的Notification，通过视图告诉用户正在验证信息。Command验证了用户信息后，发送 Notification把验证结果返回给Mediatory，告诉用户验证的结果。或者，Command也可以发送Notification执行其它的 Command*作，比如验证通过后，读取用户的详细资料。 PureMVC大大的优化了我们使用FLEX进行前台的开发，使得整个开发过程变的较为可控，但是如果放任程序员去**的使用pureMVC也会带来很大的隐患。本文内容主要记录我使用pureMVC开发原型这一个星期来使用的一些开发规范和经验总结。 1. 如果有个项目有几个开发人员共同开发，同时采用版本控制工具对项目项目的源*进行版本控制，可是维护通 知的名称着实让人烦恼，我们若要将通知名称放在同一 个类中{ApplicationFacade}就不能很好的使用版本控制工具，因为每个人都要修改这个类 {在你修改时你要看看别人是否已经修改该文件，别人若是修改了还得让他提交，然后自己更新再修改，太痛苦了!} ，而且都放在一个类里也会增加维护的难度，那么有没有什么好的办法呢？ 通常一两个人做个例子时遇到这种情况可能比较好解决，单如果参与的人较多的化，可能花在协调上面的工作 量就会比较多，为了增加开发的速度，使开发变的更加的简单，我们可以让通知名称分散到各个模块的Mediator 类中进行维护{每个模块主页面的协调类，可根据自己的系统大小控制粒度}，这样每个开发人员可以只要维护自身的通知名称或者只要与一两个人进行协调，同时我们要求每个通知名称都要包含该类所在的包路径和类名称，具体的格式可以是“通知名称+包路径.类名称”，这样我们只要保证通知名称唯一，且便于日后维护。 2. 每个Mediator，Proxy都要定一个NAME属*，通常我要求每个NAME属*必须是“包路径+类名称”，也是 为了避免不必要的冲突，找半天BUG。 3. PureMVC中Mediator似乎什么都可以坐了，Command的用处似乎不大。 这是一个错误的看法，虽然我们在Mediator中可以直接获取到Proxy，Mediator类的对象，也可以注册 Mediator，Proxy，Command，但是我们必须给自已一个约束，不然随着开发的不断深入你会发现代*也越来越乱。所以我们增加了较为严禁的约束： 3.1 通常情况在程序启动后，Mediator负责注册Command，以及派发通知和接收通知，当Mediator类需要进行当前范围外的一些*作时就可以通过派发通知的方式。一般来说页面UI主要负责页面的布局和简单的作，其他的应该交由Mediator来处理。例如，Mediator协调的UI需要获取数据，这是Mediator可以派发一个获取数据的通知（之前已经注册一个用于处理该通知的Command），然后有pureMVC会初始化被注册的 Command并执行获取数据的*作。如果你需要告知另外一个页面进行某些*作或者增加一个新的页面，也应该通过派发通知的方式来处理，应避免在当前 Mediator类中直接获取响应页面的对象或者获取Mediator类进行*作，如果是增加一个新的页面应当在页面加载后将该页面的对象作为报体通知 Command进行注册以及其他*作。 3.2 Command主要负责注册Mediator和Proxy以及协调Mediator和Proxy之间的*作，应当将复杂的*作放在这里处理。 Command的注册不必集中但也不可以太过分散，一般来说放在比功能级稍大点的Mediator中来注册（例如一个增删改查，4个页面需要不停的切换，关于这4个页面功能的Command一般来说都是放在这四个页面的上一层页面的Mediator中进行注册，也就是管理这四个页面的Mediator 中）。当我们要增加啊一个新的UI时需要通知Command来注册Mediator，需要调用model层对数据进行处理时也应通知Command来调用，如果一个Command类里的代*过多，应当考虑进行拆分，Command类应尽可能分的细点，便于维护。 3.3Proxy主要负责对数据的维护以及与服务器端进行通信处理数据。Proxy应当做到只做纯粹的数据处理不干涉过多的逻辑处理，不关心外面发生了什么事情，只要在数据处理后派发通知来通知外界即可，如果各个Proxy之间需要进行交互，那也应该在Command中来是先调用不用Proxy的方法，不要在Proxy中直接去调用另一个Proxy更不能去调用Mediator。 4.注意清除你不用的Mediator，Proxy，Command应当及时的清除，pureMVC采用观察者模式，及时的清楚能减轻系统的负担，但是有时无法做到清楚指定的Mediator等对象，所以在每次注册新的Mediator，Command，Proxy时要判断是否已经存在相同的类，然后根据自己的需要选择是重新注册还是继续使用以前的，切不可同时注册两个相同的，例如：当你有两个相同的Mediator时，你通过NAME属*去获取该对象，那究竟获取哪一个对象才是你想要的呢？
