我们通过上图可以看出，两者流程基本一致，所不同的主要是两点：RoR的Action Pack和Active Record，下面我们就这两点解释如下：

　　Action Pack

　　Action Pack是RoR的MVC组件框架；

　　View templates，相当于Struts中的Jsp；

　　URL routing，相当于struts-config.xml流程配置，RoR不是使用XML配置，而是作为脚本代码，这也是一些人吹嘘的RoR无繁多XML配置真相所在，其实，XML也是一种脚本，从某种意义上来说：XML比语言脚本更简单易写（至少语法不多）。

　　ActionController，初看相当于struts的DispatchAction，但是因为其包含业务逻辑，而我们在java中是不推荐在在控制层action中写业务逻辑的。

　　ActionController功能在于：RoR可以将浏览器的请求直接映射到ActionController类的方法上，这有些类似Struts中的DispatchAction，但是，在Java中，业务逻辑是不推荐写在表现层的控制类中的，控制类只是负责前后台流程协调，是一种Mediator模式实现，不应该让其加入更多职责；在JF中，业务逻辑是写在Service类中，JF通过自己的命令服务调用模式，也可以直接将浏览器的请求直接映射到Service类的方法上，例如，调用http://localhost//MyWeb/abc.do?method=xxx，将直接激活Service类的xxx方法，程序员直接编写xxx方法内容即可。

　　RoR的Filters过滤器也是Action Pack的一个部分，主要用来实现一些通用功能的动态插入，这在JF中是通过AOP拦截器和Decorator模式来实现的。在JiveJdon3.0中，我们通过拦截器实现了组件方法权限访问、以及缓存等通用功能。

　　Action Pack中还有Helpers功能相当于Struts的标签库，它可以把Model/ActionForm和Action以及html连接在一起，下面是RoR的Helpers如：

<form action="save_person" method="post">
　　Name: <%= text_field "person", "name", "size" => 20 %>
　　....
</form>

　　当然，RoR的Helpers有很多种类，如Form Helpers/javascriptHelpers等等，相当于一个个API 库。它的Ajax & JavaScript helpers倒是很时髦的。

　　RoR的Layouts相当于Struts的Tiles，这就不多说了。

　　Scaffolding提供一个数据表的CRUD功能实现，Scaffolding类似代码生成器，生成CRUD代码，缺点是，如果你更改了代码，Scaffolding会在覆盖，必须再更改Scaffolding设置，实际用起来比较麻烦。而JF的CRUD是一个MVC流程上的精简，属于开发框架性质，而不是代码生成，只需要通过jdonframework.xml配置：

<model key="messageId" class="com.jdon.jivejdon.model.ForumMessage">
　　<actionForm name="messageForm"/>
　　<handler>
　　　　<service ref="forumMessageService">
　　　　　　<initMethod name="initMessage"/>
　　　　　　<getMethod name="findMessage"/>
　　　　　　<createMethod name="createTopicMessage"/>
　　　　　　<updateMethod name="updateMessage"/>
　　　　　　<deleteMethod name="deleteMessage"/>
　　　　</service>
　　</handler>
</model> 

　　Active Record

　　RoR有一个Active Record组件，其实就是ORM实现，相当于Hibernate，它是Martin Fowler的 Active Record pattern实现，它是指一个既包含数据又包含行为的对象，这些数据需要持久保存到对应的数据表中。Active Record一个很明显的特征是：将数据访问逻辑也包含在这个domain对象中，通过这种办法让人们可以知道如何从数据库读写数据。

　　Active Record其实类似JF中Domain Object + Dao，也就是将Dao中对数据库的CRUD方法和Domain Object整合在一起， 我们知道，Dao模式本质是桥模式，通过Dao可以将不同的数据库访问实现分离，并且在运行时组合，但是，Martin Fowler将Dao从Domain Object分离出去的对象称为贫血对象。

　　他的这个观点笔者认为不是从技术观点，而是从领域建模角度出发的，其实从技术观点讲，将Dao从Domain Object中分离在设计上非常灵活，例如使用JF开发的JiveJdon3.0中，我们就可以在Dao层中使用Decorator模式（过滤器）加入一层缓存，这样，虽然我们Dao层使用的SQL实现，我们也是可以实现持久层缓存，JiveJdon3.0整个Dao层设计相当于一个Hibernate的微型（或者说轻量化），好处是：JiveJdon3.0这样实现的缓存可以被各层如表现层直接访问，减少路径，提升运行性能。

　　RoR秘籍

　　通过以上分析，我们也许已经明白RoR和JF定位，大家为什么突然拥戴RoR，这是因为大家比较厌恶XML配置，太复杂的XML配置只能增加开发的复杂性，而JF则在这方面从以下几个方面进行了努力：

　　表现层的struts-config.xml配置是模板化的，CRUD流程固化模板化，拷贝粘贴就可以完成配置。

　　JF自身的配置很简单，只包括两个部分Models和Services，配置语法主要集中再Models部分，语法数量不超过10个，Models负责CRUD流程配置，如果你不需要使用CRUD可以不用配置；Services是业务类配置，对于一个POJO类，只要写：<pojoService class="POJO类名" name="随便取个名" />如下： 

<pojoService name="forumService"
　　class="com.jdon.jivejdon.service.imp.ForumServiceImp"/>

<pojoService name="forumMessageService"
　　class="com.jdon.jivejdon.service.imp.ForumMessageShell"/>

　　至于，这些POJO之间的调用关系，无需指定，这由JF内置IOC微容器自动配对解决。

　　持久层试图通过JdbcTemp或SQL语句简化配置，当然Hibernate等java工具也在进步，不断重构，相信会越来越简单。
　　

　　总结：

　　相比RoR，作为DDD（Domain Driven Development framework ）实现的JF在快速开发和软件高质量上作了一个平衡，相当于在RoR（快速，但非主流语言）和Spring（高质量，但配置烦琐）之间做了一个平衡。

　　JF一直也试图争取获得国外软件专家的认可，可能会因为其他因素未能如愿，但是，作为和RoR几乎同时诞生的国产JF，作为由国人网民共同参与的结晶，已经用事实证明，国人有能力靠创新冲刺世界软件领域的前列。

　　无论如何，在RoR精神的召引下，Java世界将引来第四代语言4GL时代，同时能够满足求简单或求灵活等不同编程心理的需求，迎来新的发展。