这一段时间在 Cairngorm上搭建了一个小项目, 顺便小结一下开发过程:
1. 首先规划构建View, 将一个应用的界面, 分成适当的Mxml Component
2. view中必然涉及的需要数据的绑定, 将组件需要的数据都集中到ModelLocator中.
3. 设计事件(CairngormEvent), 也就是与用户交互的过程中以及系统运转的过程中会需要派发哪些事件,
需要注意的一点是, Cairngorm中Flex事件也需要转化成CairngormEvent
4. 设计事件的处理函数, 也就是命令. 在FrontControl中对事件和命令进行注册.
5. 命令中通过代理去调用服务.
5. 设计代理类, 在代理类中调用服务
5. 设计命令中涉及的服务(最可能的是与数据库的交互), 并添加相应的配置
6. 设计服务中需要使用的ValueObject
7. 命令中如果需要对视图组件数据进行存取, 需要通过ViewHelper来完成, 设计相应的ViewHelper.
同时在mxml中对viewHelper进行注册.
补充说明: 事件的产生不一定全部是与用户交互的结果, 也就是说不全是由View产生的.
当然大部分的事件(比如用户点击了保存按钮)是这样产生的.
在命令中也可以产生命令, 典型的就是SequenceCommand, 应用中可以把一个事件的处理分成几个步骤来完成,
完成第1个步骤后怎么通知第2个步骤开始呢, 当然还是继续派发事件啦. 在SequenceCommand在类中,
把派发事件封装了一下, 给出了一个executeNextCommand()可以直接调用.
不过在这里我也遇到了一个问题, 直接使用SequenceCommand的executeNextCommand()并不管用.
好象dispatchEvent并没有效果, 我后来是自己修改了代码, 使用Application.application.dispatchEvent才解决问题的.
Cairngorm的优点:
一. 实现了比较彻底的解耦
1. 事件机制, 对用户的响应(比如点击保存按钮), 并不是直接从View中抓取数据, 然后New一个类, 调用这个类的某个方法,
将数据保存到数据库中, 而只是简单地派发一个事件, 具体事件由谁来响应, 如何处理对他来说是透明不可见的.
2. Locator模式, Cairngorm中service, view, model的获取都是通过Locator的,
也就是说系统其他部分对于service, view, model只需要知道其ID就够了, 其内部实现等待细节都是不需要知道的.
举个例子, 传统的方法: 你要找一个叫张三的人帮你干一件事, 你需要知道张三长什么样,
然后在一个坐着10个人的大办公室里找到他, 告诉他你的要求.
而现在在这个大办公室的门口多了一个前台小姐, 你只需要告诉这个小姐,我要找张三, 然后她会帮你去找,
你根本不需要知道张三的模样.
RIA的优点: 由于Flex的原因, 系统处理是异步的.
比如, 你请求了一个比较耗时的数据库读取操作, 请求发出后, 你就可以进行其他操作了, 服务结束会产生相应事件,
然后由Command进行后续处理, 最后引发页面数据更新.