Mikel
做为对开源Flex和ActionScript富因特网应用（RIA）最新的补充，Jumpship 3.1版在2008年5月21日发布了。InfoQ为跟上RIA开发框架的 步伐，做了很多努力，其中之一就是访问了JumpShip框架的作者Jamie Scanlon。Scanlon还是Web设计室（Web design house）JSJ Studios的主人。他说之所以要开发JumpShip，是因为开发者们都会面对的可用性问题。Scanlon回忆道：
如今的JumpShip框架，在一开始时只是我一个人的小打小闹。创建它的想法事实上是在我完成了一个超大项目之后产生的， 因为那时候我可以歇下来休整休整，看看刚刚完成的项目。完成的项目使用的是MVC （一种用于SOA的快速RIA构造器）。虽然最终的软件可以工作，但是代码对于我来说还真有些复杂。controller和view都得要几百行代码。调 试时，单是查找有问题的代码所花的时间就与改正错误代码的时间一样长。我知道马上又要开始一个规模差不多的新项目，所以我特别想找到个更好的方法。
那时，我发现了 Ruby on Rails。在框架中我想要的所有东西，Ruby on Rails都一应俱全，特别是它的简练是我最想要的。尽管也基于坚实的理论，但它追求的是能把任务完成就好，而不是像“四人帮”的设计模式那样“阳春白雪 ”。我希望ActionScript也有这些，所以我开始行动起来。
Scanlon解释道：
JumpShip的目标是：重视MVC的最佳实践，但稍稍偏重于“把任务完成就好”。JumpShip不害怕为了实用性而 对理论有所牺牲。JumpShip还努力坚持Ruby on Rails的“约定优先于配置（convention over configuration）”思想。JumpShip采用的方法是：在没有一个清晰的最优解决策略时，将“把任务完成就好”当作是最优方法。对于一个框 架来说，这并不是一件坏事。采用约定就意味着可以在最佳实践的选择上少花费时间，而将精力更多地放在编码上。
就JumpShip和其他AS3框架（如ARP、Cairngorm或PureMVC）有什么不同这个问题，Scanlon回答道：
JumpShip最独特的特性之一是其中内含了标准数据模型，可以自动进行查找、排序、数据的遍历和枚举。在prototype社区已有工作的基础上，JumpShip的数据模型提供了难以置信的功能强大的数据结构，它可以在整个框架中起作用。
JumpShip和其他MVC框架之间另一个主要区别在于JumpShip在生成对其他类的引用时有意不依赖于单例（Singleton）模式这种简单方式。
他回忆道：
最近我曾写过一件自己经历的事情。我用Cairngorm构建了一个视频播放器，想把它移植到另一个需要多个播放器实例的 应用程序中。可是做完后我遇到了问题，我意识到：因为使用了单例ModelLocator和Cairngorm的EventDispatcher类，所以 只要我单击任何一个播放器实例的播放按钮，面板上所有的播放器实例都会监听到单击播放按钮这个事件，大家同时开始播放。
我坚信，在大多数的框架中，使用单例模式时，考虑得都太少了。单例模式确实能够轻而易举解决无须对每个类的引用都进行存储的问题。这使得它们使用起来非常方便，但如果确实想要构建一个部件化、组件化的环境，单例模式用起来就不一定那么舒服了，有可能会坏事。
JumpShip还有一个与其他框架的不同之处是它使用了Rails网关，通过借助于Rails的RESTful Web服务为使用者提供了一个类库，这样就可以使用Rails的后台完成基本的CRUD(Create-Read-Update-Delete，创建－读 取－修改－删除)操作。至于JumpShip和Ruby on Rails的集成，Scanlon 解释道：
框架能有多简单、应该给开发带来多大方便，Ruby on Rails就是我心中的典范。基于使用Ruby on Rails的经验，我总想在框架中定义一个非常管用的数据模型。Rails中有一个ActiveRecord类，它是数据库表的抽象，既可以作基本的 CRUD操作，也可以完成查找、排序和数据遍历。当你开始将数据当成是数据库表的抽象时，你就会希望那些对数据进行的各类基本操作都是现成的。假定我的应 用程序中的数据都来自于数据库表中存储的各种值，我想让数据模型知道怎样对数据进行查找、排序、遍历和修改。
我还想只搞一个数据模型，让它哪里都能工作。我不想在每个应用程序中都得定义值对象，即使明明知道这些值对象再也不会在别 处使用了。这种一个数据模型不仅仅在当前项目使用，而可以到处使用的概念，在ActionScript里还是个新想法。这样不仅节省了开发时间，而且还促 使程序员去思考像数据模型这样有助于应用程序和开发工作的一些事情。服务器给你什么形式的数据你就解析、存储什么样的数据，这并不是一个好方法。开发者们 常常会陷入这样的误区：把他们的数据模型构建的与他们得到的原始数据（如XML、JSON或原始对象）一模一样。从服务器传来的数据所含的结构很可能非常 适合于后台的业务逻辑。但是，做为前台的开发者，我们没有义务使那些传来的数据结构保持不变。我们可以而且也应该让数据为我们服务，而不是相反的去为数据 服务。
Scanlon对Rails网关也进行了评论，他回忆道：
在我开发JumpShip时，要使用rails后台，可是几乎没有任何资料讲解Rails如何与ActionScript 彼此互相通信。我经历了短暂的挫折，努力尝试来完成这个任务。但最后，并不像我想像的那么难，我只想说清楚我是怎么实现的。我想让Rails的开发者明白 他们开发的程序如何与Flash前台协同工作；我也想告诉Flash/Flex的开发者们不要太过专注于Flash Remoting和AMF，还要留意Web服务中其它更多的东西。
事实说明，并不是只有我一个人在走这条路。几个月以后，Adobe发表了一篇关于Flex和Rails协同工作的文章。不 管怎样，我一直坚持在改进JumpShip 的Rails网关，因为我觉得Rails网关是有价值的，它为Rails和ActionScript的协同工作提供了一种解决方案，不与Adobe的 Flex相关，它利用了我在做JumpShip数据模型时的一些成果。
我意识到拥有定义的数据模型的另一个好处：通过RESTful服务和XML就可以与Rails进行通信，可以将来自 Rails的所有数据转换成标准的JumpShip数据模型。因此，你可以创建一个叫做'users'的数据模型，并告诉JumpShip的Rails网 关在服务器上进行查询。网关自己知道在users数据库表中进行查询，并且会将XML查询结果转换成为JumpShip数据模型。这确实相当酷！你还可以 选一个JumpShip数据模型，告诉网关把它存储起来。网关知道怎样将数据模型转换成XML，并告诉Rails将其存储到数据库中。
尽管Rails网关对特定的一群ActionScript开发者有用，但我还是很惊喜的从要使用Flash做为前台的Rails开发者那里得到了大量积极反馈，他们认为 Rails网关很有用。
当InfoQ询问Scanlon在JumpShip框架中最想进行哪三大改进时，他回答道：
我会把文档创建工作列到第一位。我现在正在着手做这事。好的文档在帮助理解该框架的威力方面至关重要。但是太耗时间了，在文档方面，我自己也没有太好的习惯。
我也希望能加强这个框架的社区建设工作。我希望随着社区的扩充，有更多的人可以贡献出他们的想法和经验，这样框架就会不断成长和进步。
最后，我希望JumpShip的适用范围更广，它也能用在Flex框架中。JumpShip起初虽然是一个Flash框 架，因此我希望它在能继续为使用Flash的开发者提供帮助的同时，也能吸引越来越多的Flex开发者。尽管该框架在两种环境下都可以工作得很好，但是普 通Flex开发者会发现一些异于原来的新概念。我的目标是降低Flex开发者使用JumpShip的门槛，这样就会让他们像使用Flex相关的框架（如 Cairngorm）一样简单地使用JumpShip框架。
Scanlon指出JumpShip也非常适于创建可移植可复用的代码，比如小构件和组件，因为它更少的依赖于单例模式， 更不容易引起冲突。总之，Scanlon 把JumpShip 当作是一个实用的框架，该框架适合于那些希望迅速完成任务，而不过多考虑设计模式理论或者实现MVC最好方法的开发者们。
查看英文原文：ActionScript Framework JumpShip 3.1 Released with Extensive Ruby on Rails Support
