PureMVC使用心得
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属性去获取该对象，那究竟获取哪一个对象才是你想要的呢？