第六章:快速有效地使用Cairngorm和Flex开发
在这个系列最后的文章上, 让我们花费一点时间站在Cairngorm最高点上往下看,看看我们到底爬了多高了。
在学习了上面各章后, 你现在已经具备了开发RIA(rich Internet application)相应的知识、工具, 和专门技术, 运用你所学的课程就能安全严密地应付任一个应用开发项目, 不管问题一开始有多么地复杂。
应用这些课程学到的知识, 你能一致地, 有效地, 迅速地完成RIA的设计、开发, 充满信心地提交RIA,因为你所使用的方法都是在各种各样复杂的挑战中被证明是有效的。
让我们快速回顾一下Cairngorm的不同模块及它们是如何协作工作的,来巩固知识。回忆一下你为了达到传递feature到应用程序的目标所必须设置的基础结构吧。
最后,让我们置身于CairngormStore的开发中,不断练习来确定你现在已经可以直接应用Cairngorm开发你自己的应用程序,很多Flex开发人员就是这样成功的。
让我们直入主题，来复习一下Cairngorm的结构。这样来比喻这种结构：Cairngorm能很轻松地在人跟机器之间建立一种和谐，听取用户的需求，确定用户获得他们所需的，然后将结果反馈给用户。
前台控制器监听用户动作
用户处于这次会话的主导地位。你的RIA等待来自用户的一些提示。这些提示包括：点击按钮，拖放图标，双击行或是发送表单，这些都叫做“用户动作”
Cairngorm 将这些用户动作翻译成Cairngorm事件。无论是点击，按下，拖曳，放下，提交的事件都代表用户的需求，你使用事件广播器广播事件。事件广播器是Cairngorm会话的开始。
前台控制器模块是Cairngorm事件的唯一监听者。聚集不同事件句柄，前台控制器确保满足用户的需求。
无论如何，前台控制器不做具体的工作。它只是一个管理者，不是一个工人。前台控制器负责管理着一份名单“谁做什么？”，一份命令名单，命令对应着相应的事件。
命令做全部的工作
一旦前台控制器发现一个事件对应的命令，它将告诉命令去执行。前台控制器告诉任一或每个命令去做什么以一种一致的方式：前台控制器调用命令中的execute()方法，但命令会做它自己特殊的事。
将服务器端的业务逻辑委派给业务代理
很多情况下，命令需要服务器支持。在RIA中，许多业务逻辑执行在客户端。但是或多或少，你需要将不些业务逻辑移到服务器端执行。
命 令不关心一些事是如何完成的。它们只关心它完成了。命令更喜欢将服务器端的业务逻辑委派给其它类。这是好事，毕竟，一些命令要实现远程任务，它们都会需要 相同的服务。另外，对全部命令来说，事务逻辑还没有写在服务器端。可能命令只是简单调用虚构的业务代理类，服务器端结构中并不存在这样的类，但是业务代理 提供了一种接口，以备未来使用。
所以不论何时你有业务逻辑，将它放在业务代理类中，这样你的命令可以调用其中的方法。
业务代理在服务定位器中寻找服务
业务代理为命令和在服务器端的服务间提供了一种完美的接口。这些服务可能是Java服务，ColdFusion组件，Web Services,或是简单的HTTP服务。业务代理对待这些服务都一样，当命令提出时调用它们，当服务是可用时立即返回结果给命令。
无论如何，这些服务的具体实现(Java类名或是CFCs,无论它们有名称或是没名称的服务，WSDL文件，或是HTTP服务的URLs)都装入一个服务库里，叫做服务定位器。
服务定位器是你的RIA需要的全部服务的目录。因为只有业务代理有权调用服务，只有业务代理使用服务定位器在调用这些服务前按名称定位服务(不关心服务的实现),返回结果给命令类。
记住，任何一个命令类（负责响应服务调用，从业务代理中返回数据）都必须实现响应接口。这样，业务代理知道命令有一个onResult()方法来获取全部结果，一个onFault()方法来截获错误。
以Value Objects来传输数据
数据在客户端和服务器端传输时会发生什么，在客户端又如何？Cairngorm强调你可以处理数据可以稍微自由些，将它装入Value Objects，Value Objects强调了数据在业务形式上是什么(它是规则)，而不是技术形式上是什么（包含字符和数字对象的数组）。
模型定位器中的存储状态和模型关联视图
最后，你的应用程序必须与用户交流。在Cairngorm中，模型定位器保存着全部应用程序状态。虽然我们不关心用户的体验是如何用MXML和ActionScript实现的，但是我们强调在任何地方视图总是动态的，视图使用数据绑定将数据绑定到模型定位器。
模型定位器只包含Value Objects.当你的命令类使用业务代理去调用服务器端的业务逻辑时，它实现了响应接口，在onResult()方法实现接收Value Objects或是Value Objects集合。
Cairngorm应用程序会话的最后部分引起的结果是命令更新了模型定位器中的用Value Objects表示的新状态。模型定位器使用数据绑定来通知视图，用户接口更新来显示新的数据，完成用户会话。
以上我冗长的描述是关于通过Cairngorm架构不同设计模块的控制流。任一或是每个在应用程序中的feature都按照相同的执行过程，用户动作生成事件，事件调用服务，数据传回模型。
向Cairngorm应用程序添加新的Feature
当你向Cairngorm应用程序加入一个新的feature时，它的过程很简单：
1．注册一个事件和命令，用前台控制器使用addCommand()方法
2.实现一个新的命令如下：
a.实现execute()方法
b.实现onResult()方法从服务器中获取结果
i.用于更新模型定位器的任何结果
ii.模型定位器自动更新视图。
3.加入任何新的服务调用，在命令需要业务代理时。
4．如果这些服务调用需要新的服务时，把它们加入到服务定位器中。
另外，你需要创建Value Objects用于在命令与业务代理间，业务代理与服务器间传输，或者存储到模型定位器中。更特别的，你的ValueObjects可以在你开发应用程序前就存在，你可以不断重用它们，当你向应用程序加入新的feature时。
相似的，当你的应用程序不断扩大时，服务器端服务很快就禁闭了，应用程序开发速度更快，如下：
1．注册一个事件和命令，用前台控制器使用addCommand()方法。
2．实现一个新的命令。
这真的就是全部的。
调试一个Cairngorm应用程序
此外，调试一个Cairngorm应用程序按照相同的可见步骤。如果一个需求模块不能响应用户的动作，调试过程总是这样：
1．检查事件是否在前台控制器中注册过。
2．检查命令中的execute()方法是否被控制器调用。
3．检查相应的代理方法是否被调用。
4．检查命令中的onResult()方法是否被调用。
5．检查模型定位器中的模型是否更新。
用这五步骤，你可以很轻松地分离问题，并修复它。
一个feature经常出现在电子商务应用程序中，它叫做“需求列表”,一种产品的临时列表用于暂时存放用户以后可能要买的产品但还未加入到购物车中。
在一个灵活的团队中，需求列表的需求或是说“story”，在CairngormStore中可以这样理解：
在这个系列最后的文章上, 让我们花费一点时间站在Cairngorm最高点上往下看,看看我们到底爬了多高了。
在学习了上面各章后, 你现在已经具备了开发RIA(rich Internet application)相应的知识、工具, 和专门技术, 运用你所学的课程就能安全严密地应付任一个应用开发项目, 不管问题一开始有多么地复杂。
应用这些课程学到的知识, 你能一致地, 有效地, 迅速地完成RIA的设计、开发, 充满信心地提交RIA,因为你所使用的方法都是在各种各样复杂的挑战中被证明是有效的。
让我们快速回顾一下Cairngorm的不同模块及它们是如何协作工作的,来巩固知识。回忆一下你为了达到传递feature到应用程序的目标所必须设置的基础结构吧。
最后,让我们置身于CairngormStore的开发中,不断练习来确定你现在已经可以直接应用Cairngorm开发你自己的应用程序,很多Flex开发人员就是这样成功的。
让我们直入主题，来复习一下Cairngorm的结构。这样来比喻这种结构：Cairngorm能很轻松地在人跟机器之间建立一种和谐，听取用户的需求，确定用户获得他们所需的，然后将结果反馈给用户。
前台控制器监听用户动作
用户处于这次会话的主导地位。你的RIA等待来自用户的一些提示。这些提示包括：点击按钮，拖放图标，双击行或是发送表单，这些都叫做“用户动作”
Cairngorm 将这些用户动作翻译成Cairngorm事件。无论是点击，按下，拖曳，放下，提交的事件都代表用户的需求，你使用事件广播器广播事件。事件广播器是Cairngorm会话的开始。
前台控制器模块是Cairngorm事件的唯一监听者。聚集不同事件句柄，前台控制器确保满足用户的需求。
无论如何，前台控制器不做具体的工作。它只是一个管理者，不是一个工人。前台控制器负责管理着一份名单“谁做什么？”，一份命令名单，命令对应着相应的事件。
命令做全部的工作
一旦前台控制器发现一个事件对应的命令，它将告诉命令去执行。前台控制器告诉任一或每个命令去做什么以一种一致的方式：前台控制器调用命令中的execute()方法，但命令会做它自己特殊的事。
将服务器端的业务逻辑委派给业务代理
很多情况下，命令需要服务器支持。在RIA中，许多业务逻辑执行在客户端。但是或多或少，你需要将不些业务逻辑移到服务器端执行。
命 令不关心一些事是如何完成的。它们只关心它完成了。命令更喜欢将服务器端的业务逻辑委派给其它类。这是好事，毕竟，一些命令要实现远程任务，它们都会需要 相同的服务。另外，对全部命令来说，事务逻辑还没有写在服务器端。可能命令只是简单调用虚构的业务代理类，服务器端结构中并不存在这样的类，但是业务代理 提供了一种接口，以备未来使用。
所以不论何时你有业务逻辑，将它放在业务代理类中，这样你的命令可以调用其中的方法。
业务代理在服务定位器中寻找服务
业务代理为命令和在服务器端的服务间提供了一种完美的接口。这些服务可能是Java服务，ColdFusion组件，Web Services,或是简单的HTTP服务。业务代理对待这些服务都一样，当命令提出时调用它们，当服务是可用时立即返回结果给命令。
无论如何，这些服务的具体实现(Java类名或是CFCs,无论它们有名称或是没名称的服务，WSDL文件，或是HTTP服务的URLs)都装入一个服务库里，叫做服务定位器。
服务定位器是你的RIA需要的全部服务的目录。因为只有业务代理有权调用服务，只有业务代理使用服务定位器在调用这些服务前按名称定位服务(不关心服务的实现),返回结果给命令类。
记住，任何一个命令类（负责响应服务调用，从业务代理中返回数据）都必须实现响应接口。这样，业务代理知道命令有一个onResult()方法来获取全部结果，一个onFault()方法来截获错误。
以Value Objects来传输数据
数据在客户端和服务器端传输时会发生什么，在客户端又如何？Cairngorm强调你可以处理数据可以稍微自由些，将它装入Value Objects，Value Objects强调了数据在业务形式上是什么(它是规则)，而不是技术形式上是什么（包含字符和数字对象的数组）。
模型定位器中的存储状态和模型关联视图
最后，你的应用程序必须与用户交流。在Cairngorm中，模型定位器保存着全部应用程序状态。虽然我们不关心用户的体验是如何用MXML和ActionScript实现的，但是我们强调在任何地方视图总是动态的，视图使用数据绑定将数据绑定到模型定位器。
模型定位器只包含Value Objects.当你的命令类使用业务代理去调用服务器端的业务逻辑时，它实现了响应接口，在onResult()方法实现接收Value Objects或是Value Objects集合。
Cairngorm应用程序会话的最后部分引起的结果是命令更新了模型定位器中的用Value Objects表示的新状态。模型定位器使用数据绑定来通知视图，用户接口更新来显示新的数据，完成用户会话。
以上我冗长的描述是关于通过Cairngorm架构不同设计模块的控制流。任一或是每个在应用程序中的feature都按照相同的执行过程，用户动作生成事件，事件调用服务，数据传回模型。
向Cairngorm应用程序添加新的Feature
当你向Cairngorm应用程序加入一个新的feature时，它的过程很简单：
1．注册一个事件和命令，用前台控制器使用addCommand()方法
2.实现一个新的命令如下：
a.实现execute()方法
b.实现onResult()方法从服务器中获取结果
i.用于更新模型定位器的任何结果
ii.模型定位器自动更新视图。
3.加入任何新的服务调用，在命令需要业务代理时。
4．如果这些服务调用需要新的服务时，把它们加入到服务定位器中。
另外，你需要创建Value Objects用于在命令与业务代理间，业务代理与服务器间传输，或者存储到模型定位器中。更特别的，你的ValueObjects可以在你开发应用程序前就存在，你可以不断重用它们，当你向应用程序加入新的feature时。
相似的，当你的应用程序不断扩大时，服务器端服务很快就禁闭了，应用程序开发速度更快，如下：
1．注册一个事件和命令，用前台控制器使用addCommand()方法。
2．实现一个新的命令。
这真的就是全部的。
调试一个Cairngorm应用程序
此外，调试一个Cairngorm应用程序按照相同的可见步骤。如果一个需求模块不能响应用户的动作，调试过程总是这样：
1．检查事件是否在前台控制器中注册过。
2．检查命令中的execute()方法是否被控制器调用。
3．检查相应的代理方法是否被调用。
4．检查命令中的onResult()方法是否被调用。
5．检查模型定位器中的模型是否更新。
用这五步骤，你可以很轻松地分离问题，并修复它。
一个feature经常出现在电子商务应用程序中，它叫做“需求列表”,一种产品的临时列表用于暂时存放用户以后可能要买的产品但还未加入到购物车中。
在一个灵活的团队中，需求列表的需求或是说“story”，在CairngormStore中可以这样理解：
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
