http://www.martinfowler.com/bliki/
http://java.ccidnet.com/art/297/20060508/547541_1.html
本文试图比较同属快速开发性质的Ruby on Rails（以下简称RoR）和Jdon Framework（以下简称JF）在架构上异同，供大家在实际架构选择中比较。
RoR 是一个使用Ruby语言写就的Web应用框架，Ruby语言是类似Python, Smalltalk, PHP和Perl的动态类型语言。从新特点层面看，Ruby on Rails并没有提供比其他已经存在的Web应用框架新的东西，它的唯一特点就是快速开发。RoR大概诞生于2004年6月份。
JF是使用Java语言编写的、基于Ioc/AOP微容器的快速开发工具。JF是基于JdonSD构件库增删改查框架基础上发展起来的，1.0版本是在2004 年12月底完成。当时推出时很难定位，时至今日，它应该是Ruby on Rails、Spring和JBoss容器三个概念的一个中间体。属于域驱动开发框架（DDDD：omain Driven Development framework ）。
JF虽是笔者操作完成，其实它是国人网络结晶的开源产物，很多需求和思想都来自Jdon社区热情参与者，看到很多初学者总是为简单和灵活做痛苦选择，为了写一个简单系统，要么走入Jsp+JavaBeans误区，要么被复杂技术配置缠身，忘记业务本职工作。JF 推出后，道友提出各种建议甚至猛烈批判，这些都形成了JF发展动力，促进JF完善。从用户出发的简易之道使JF的起点和立意一下和RoR这样国外产品走到了一起，下面我们详细进行一下两者架构比较。
语言之争
RoR代表的是动态类型语言派别；而Java是一种静态类型语言，当初Java刚刚诞生时，这种两种类型派别之争曾经发生在Java和Smalltalk之间，后来现实选择了Java这样静态类型语言，关键原因时动态类型语言在编程时难以找出其一些潜在的语言Bug。
但是，随着软件工程中单元测试的重视，动态类型语言+单元测试的结合克服了以上缺憾，从而使得RoR这样得动态类型语言重新东山再起。
促成RoR受到敏捷工程派别的领域专家（如Martin Fowler）推崇另外一个原因是，它被认为是一种domain-specific languages(DSL)实现，DSL是一种专门供领域建模专家（也就是系统分析师）使用的语言，这些领域专家不同于程序高手，他们有一套自己认知世界和表达世界的思维和方式（如UML），因此，他们不感兴趣于软件设计细节，希望软件能够按照他们分析设计的结果去运行和执行就可以了。
其实，DSL并不是一个全新理念，它已经在我们软件领域中反复出现，例如：我们很多人是关系数据库领域专家，所以，尽管由O/R Mapping这样工具出现，但是并没有改变这些领域专家表达方式，他们还是使用SQL等严谨的数学思维来实现他们的表达方式。
DSL概念非常好，但是是否有必要重新搞一套DSL语言则涉及很多方面的问题，新的语言总会在实践中有新的陷阱，Java经过十多年发展，成熟和发展是其特点。
当然，别以为RoR顶着DSL新名词就是一个非常好的东西，对其本质微词已经不绝于耳，有人认为它实质不过就是1994的Visual FoxPro（Ruby on Rails is a Bloody Square Turd ），提出该观点的作者认为：为什么我们在一个没有重构以及调试支持的编码环境中工作？为什么还要重覆以前的痛苦呢？如果你确实喜欢RoR的ActiveRecord，为什么不用. NET呢？RoR 不是开发Web应用平台， RoR is a cult（RoR是宗教崇拜，笔者注：大概因为是因为所谓大师级的人推荐原因）.
无论如何，让我们抛开争执，通过比较看看RoR一些特点。
多层架构
现在多层架构已经深入人心，多层主要是指表现层MVC、业务层和持久层多层分离的体系，由于Java是一个技术自由选择的世界，因此，每个层面都有不同的具体框架技术供选择， 提供选择是一种好事，但是又可能是一种坏事，需要应用者花费精力学习和研究，这非常类似我们购物。
在微软世界，由于各层框架技术几乎都是由一家提供的，所以，.NET就索性将这些框架直接集成到IDE开发工具，对于有的程序员感觉.NET用起来很快，将开发工具和框架混合成一体，但这是以绑定为代价的，甚至有程序员反感Java世界IDE+框架的开发方式，认为在开发工具之外还会多一个框架，并且认为违背KISS（keep it simple and stupid）原则，其实不然，关键是追求KISS原则的同时，不要使自己受制于某个厂商或平台，使自己变得简单以及愚蠢
（失去自己作为客户的上帝位置，被厂商忽视，成为简单而愚蠢的人），此为KMSS（keep me simple and stupid）。
在Java世界，多层结构实现路径很多，从MVC到持久层框架有各种选择，例如我们可以使用Struts以及Hibernate组合成一个J2EE多层 应用系统。
Rails也提供了model/view/controller多层实现，但是各层的实现框架也确定下来，省却了程序员在多个框架之间选择带来的“麻烦”（这是相对的）。
而Jdon Framework则类似RoR这种提供缺省各层实现设计，表现层在struts基础上进行了CRUD流程抽象；通过提供JdbcTemp实现持久层技术，当然，持久层具体实现也可以选择hibernate等其他框架实现，秉承提供缺省的，但是也是可替换的宗旨。
下图是两者各层架构比较图：
我们通过上图可以看出，两者流程基本一致，所不同的主要是两点：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模式来实现的，见AOP vs Decorator 一文，在JiveJdon3.0中，我们通过拦截器实现了组件方法权限访问、以及缓存等通用功能。
Action Pack中还有Helpers功能相当于Struts的标签库，它可以把Model/ActionForm和Action以及html连接在一起，下面是RoR的Helpers如：
Name: <%= text_field "person", "name", "size" => 20 %>
....
当然，RoR的Helpers有很多种类，如Form Helpers/javascriptHelpers等等，相当于一个个API 库。它的Ajax & JavaScript helpers倒是很时髦的。
RoR的Layouts相当于Struts的Tiles，这就不多说了。
Scaffolding提供一个数据表的CRUD功能实现，Scaffolding类似代码生成器，生成CRUD代码，缺点是，如果你更改了代码， Scaffolding会在覆盖，必须再更改Scaffolding设置，实际用起来比较麻烦。而JF的CRUD是一个MVC流程上的精简，属于开发框架性质，而不是代码生成，只需要通过jdonframework.xml配置：
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则在这方面从以下几个方面进行了努力：
1. 表现层的struts-config.xml配置是模板化的，CRUD流程固化模板化，拷贝粘贴就可以完成配置。
2. JF自身的配置很简单，只包括两个部分Models和Services，配置语法主要集中再Models部分，语法数量不超过10个，Models负责CRUD流程配置，如果你不需要使用CRUD可以不用配置；Services是业务类配置，对于一个POJO类，只要写：如下：
class="com.jdon.jivejdon.service.imp.ForumServiceImp"/>
class="com.jdon.jivejdon.service.imp.ForumMessageShell"/>
至于，这些POJO之间的调用关系，无需指定，这由JF内置IOC微容器自动配对解决。
3. 持久层试图通过JdbcTemp或SQL语句简化配置，当然Hibernate等java工具也在进步，不断重构，相信会越来越简单。
总结：相比RoR，作为DDD（Domain Driven Development framework ）实现的JF在快速开发和软件高质量上作了一个平衡，相当于在RoR（快速，但非主流语言）和Spring（高质量，但配置烦琐）之间做了一个平衡。
JF一直也试图争取获得国外软件专家的认可，可能会因为其他因素未能如愿，但是，作为和RoR几乎同时诞生的国产JF，作为由国人网民共同参与的结晶，已经用事实证明，国人有能力靠创新冲刺世界软件领域的前列。
无论如何，在RoR精神的召引下，Java世界将引来第四代语言4GL时代，同时能够满足求简单或求灵活等不同编程心理的需求，迎来新的发展
9月14日，我在CSDN上看到了透明的一篇谬文 http://blog.csdn.net/gigix/archive/2006/09/11/1210180.aspx，论调十分之荒谬。所以，我在公司里冒着被老板发现的危险，即兴写了一篇短文http://blog.csdn.net/shendl/archive/2006/09/14/1222587.aspx ，予以驳斥。
CSDN的编辑把它和透明的那篇文章放在了一起。跟贴者甚众，令我没想到的是，我的文章居然被不少跟贴者驳斥，而且语言极尽讽刺、挖苦之能事。
我并不反对就技术问题争论，也不是不允许别人就我的文章和观点与我辩论。相反，我一向都非常欢迎同行指正我的错误，能够使我有所提高。
但是，多年与人打交道的经验让我深深地相信这样一个真理：“你永远无法说服不想被你说服的人。”
这次众多驳斥我的跟贴再一次验证了这样一个真理。
我的文章由于成文比较仓促，所以确实在文笔上有一些漏洞，遣词造句也不是很妥当。但我认为，一个严肃的辩论者，是不会咬文嚼字的寻找对方文法上的弱点的。否则的话，除了数学公理之外，没什么话可以说了！
对于这样的人，在我眼里，并不是在污辱我的智商（尽管他是这样以为的），而是在侮辱他自己的智商。这说明他完全不具备与人交流的能力。
如果一定要咬文嚼字，那么所有判断句都不可以在文章里用了。Java会消亡吗？废话，一定会。宇宙都会消亡，什么能不消亡？
论点：
透明的意思是，3-5年内，Ruby将占据企业级应用市场的主流。也就是JavaEE和今天的Ruby换个位子。我认为，这是不可能的。Java平台至少能够继续占据、企业级应用市场主流地位10年。
Java平台优势和对动态OO的支持
有人说我不懂Ruby，也不懂Java。这我就不敢苟同了。我是不懂Ruby，但并不代表我不懂Ruby,Python,Smalltalk语言为代表的动态面向对象语言的机制。对于Java，我也许不比某些人懂得多，但也绝不会比一般的Java程序员懂得少。
我对Ruby的认识，仅仅是今年5月Martin Fowler先生在上海交大作的一次演讲中Martin Fowler的Ruby编程演示。我还略为研究过Smalltalk和Python的语法。但是它们的类库，我没有研究过。
因为，我还不打算靠它们吃饭，那厚厚的专用类库对我而言是没有价值的。
Spring的AOP实现需要使用“反射”这种动态技术。这也是促成我当年研究Smalltalk和Python这样的动态面向对象语言的原因。我也十分折服于动态面向对象编程技术的强大能力。我一直认为动态OO技术在未来，将在编程中发挥越来越大的作用，也一直希望JVM能够增加更多的动态技术。我还曾经写过文章为动态OO技术摇旗呐喊过，此初衷依然不改！
Java作为一个平台也确实有这样的能力，而且也正在向这个方面发展，JVM将会支持更多的动态OO技术。
.NET平台当年推出之时，就以支持多种静态面向对象编程语言为卖点。VB.NET,C#，Delphi,托管C++这4种主流的面向对象编程语言都可以在.NET平台上运行。
同样都是静态面向对象编程语言，它们之间除了关键字不同之外，有什么本质上的区别吗？没有！VB.NET和C#是我所熟悉的两种.NET语言。它们之间本质上确实没什么区别。唯一的区别是，.NET平台的技术更新时，C#会先得到支持，VB.NET要晚一些。比如，事件机制，.NET1.1时，VB.NET用的是类似于Java1.0时的机制，C#用的是Java更新版本的机制。我想，应该是因为微软最重视C#的缘故吧。
.NET平台同时支持多种类似的语言，虽然在市场上有吸引VB,C++,Delphi,Java等程序员的作用，但在技术上却导致了开发资源的浪费。一种技术，要提供多个语言的实现。这比Java平台只支持Java这一种静态面向对象编程语言要低效的多。我在发现了微软优先关照C#之后，就决定从VB.NET上转到C#上，以免吃亏！自从Delphi投入.NET平台之后，日渐式微，这也是一个平台上不需要多种类似语言的明证！可以预见，.NET平台上C#独大的趋势还会继续下去。
.NET支持多种类似语言的另一个问题是，分裂了开发者社区。VB.NET,C#，Delphi，还有J#，托管C++，它们的语言原理和能力实际上都差不多，都是静态面向对象语言，但是，由于语法不同，就分裂成了几个开发者社区，彼此交流都不方便。
在我上一篇文章的评论者中，有人说我说错了，Java平台上除了Java之外还有Beanshell等语言。拜托！兄弟，你的理解力没什么问题吧？我说的是Java平台上只有一种官方支持的静态面向对象编程语言。就是和.NET比较而言的。
Java平台官方支持C++,C#,VB.NET,Delphi,J#吗？
Beanshell是一种动态面向对象语言，而且Sun官方可没有支持它！
现在，Java平台正在增强对动态编程能力的支持。目前，开源社区提供了Beanshell,JRuby,JPython,Groovy等面向对象编程语言。我相信，最后，在Java平台上也会只剩下一种主流的动态面向对象编程语言。未来，Java平台上会剩下两种主流的编程语言：静态面向对象编程语言类型是Java；动态面向对象编程语言是上面中的一种，也许是Groovy,也许是JRuby。
将来，我们Java程序员将有2件编程利器：Java和动态OO语言。对于编程问题，将能够更加游刃有余！底层的API类库，既可以是Java，也可以是其它动态OO语言所编写。反正都一样是.class文件，Java和动态OO语言都可以调用。
这就是未来！Ruby和Python这两种平台将会继续惨淡的过日子，也许不会消亡，但成不了主流。不是因为它们的语法不好，机制不行，而是因为它们缺少Java平台上那样多的API，也缺少熟悉这些API的程序员。
它们的灵魂将会飞到Java平台上，以JRuby,JPython的形式生存下来，在Java平台上发展起来。
静态OO语言和动态OO语言的优劣
接下来，再谈一谈静态OO语言和动态OO语言的优劣的问题。
我欣赏动态OO语言，smalltalk虽然出现的很早，开发者甚少，但是在它的社区中却诞生许多著名的程序员和设计模式等思想。MVC模式，XP极限编程等我所尊敬的技术都出自smalltalk。
但是，静态OO语言一直占据着主流的地位，也不是没有原因的。除了编译型语言的执行速度比解释型语言快之外，静态OO语言还有其它的优势。速度的快慢，在今天来看，并不是十分重要。Java比C++慢一些，但现在测试下来，C++最多比Java快一倍而已（不要跟我说某一个程序速度差很多，我这里指的是一般的程序，不作特别的优化和劣化处理）。只要速度不是相差一个数量级，就不是问题。
静态OO语言意味着更严格的语法，更多的编辑和编译时的检查步骤。更强的纠错能力，不正是编程语言发展的一个标准吗？不是可以更好的提高效率吗？
5月份那次看Martin Fowler先生演示编写Ruby程序，IDE弱弱的报错能力让Martin先生也伤了不少脑筋！
不错，Ruby不需要给变量声明类型。想指向哪个类型，就指向哪个类型。但是，指错了呢？只有在运行时才能发现类型指错了。如果这是个复杂的程序，有很多执行路径呢？如果测试人员没能够穷尽所有这些可能的路径呢？这个错误岂不是会漏给用户？
不错，借助于测试驱动开发，是可以降低出错几率。但是，测试驱动开发也不是测试的银弹，不能保证能够找出所有的错误。而且，静态编程语言也可以使用测试驱动开发技术。
市场预测
我预测，未来3-5年，Java平台和.NET平台都会增加对动态OO语言的支持力度，它们上面的动态OO语言将会达到实用化的程度。而Python和Ruby将会继续维持现在这样的市场规模。仍然处于边缘。Python和Ruby的解释器平台不会得到多大范围的应用。就像今天，Web2.0的那些小网站带来了Web2.0的概念，但最后是门户网站Yahoo,Sina等占据了Web2.0的市场。
DSL特定领域语言
接下来，说说DSL特定领域语言的问题。Matin Fowler最近转调了。我记得原来他非常支持XML格式的作用。但是，最近他说Ruby是最合适的DSL语言。尽管我仍然十分敬佩Martin Fowler先生，但是对他的这个观点，我不敢苟同。我认为，DSL语言还是应该使用xml格式，而不是使用Ruby这种类英语的编程语言来描述。
DSL可以说是一种“元数据”。用来描述程序。现在有2种元数据：标注和配置文件。
1.标注是.net首先引入的。Java在5.0之后也引入了。标注写在源代码中，和关键字一样，只是标注是可以自定义的。
标注的优点是，简单。缺点是表达能力不强。
2.配置文件，一般又分为3种：属性文件，一般文本文件和xml文件。
属性文件中的数据是以“名—值”对的形式表示的。缺乏数据之间的关系结构。表达能力不强。
文本文件，就是直接在文本中按照规定的语法写上一段文本。类似自然语言，只是语法的限制很强。语法检查，是一个大问题。如果没有按照语法写，就会发生运行时错误。
Xml文件，是层次结构的。它的前身是层次数据库。它的格式严谨，语法容易验证，规则容易定义。只是稍微复杂一点，需要写上元素名。
但是，总的来说，XML文件格式的DSL还是功能最强大，语法验证能力最强，目前也是首先的DSL语言的载体。
除了使用元数据之外，直接使用编程语言也是可以实现高等级的功能的。如，传统的不使用xml配置文件的Java编程。Java作为一种编译语言，需要编译，不使用xml等配置，就不是很方便。
而Ruby作为解释型语言，直接修改源代码是非常方便的。我想这大概就是Martin Fowler先生关于使用Ruby作为DSL的原因吧。
但是，使用DSL语言的用户，他懂Ruby吗？懂编程吗？愿意查看和修改源代码吗？我们中国的用户懂英语吗？
我认为，DSL使用XML文件还是首选！
OO就是银弹！
最后，谈谈关于OO的问题。有网友说我“言必OO?OO就是银弹吗?”。这里我回答他：OO就是银弹！
我Blog上的副标题是：“以OO为中心，坚定不移的走Spring道路”。
面向对象编程，给我们带来了多少API类库。Int,String等基本的数据类型，以及顺序、条件、循环3种控制流这样简单、细粒度的元素，通过类被封装了起来，今天已经能够通过层层叠叠的类支持对现实世界的种种对象的模拟和抽象。
借助于类库，众多的DSL特定领域语言已经被广泛使用。今天的java程序员使用了更多的配置文件（这就是DSL）来编程。如Ant配置文件，Hibernate配置文件，Spring配置文件等等。
最近，我正在学习jBPM。jBPM也是一个Java类库。通过Java类，它提供了一个DSL语言框架。我们能够使用xml配置文件，编写DSL语言：jpdl,bpel规范的。实现工作流、BPM等。
当然，除了OOP之外，还有AOP。但是，AOP只是OOP的补充。OOP能够实现绝大部分的抽象模拟任务。
认为OO无用的程序员，可能工作在嵌入式开发等与硬件有关的工作领域。他们的编程领域中，业务逻辑比较简单，不需要过多的抽象层次。
但是，这并不能成为否定OO作用的理由。你用不着OO，并不代表OO没用，并不代表OO不是银弹。
OO已经给我们带来了多大的变化啊！Java的成功就是一例。
还是毛主席的那句话：“没有调查，就没有发言权”。对此我也是深有体会的，曾经也犯过很多错。对于自己不懂的领域，硬是认为别人的说法荒谬。后来，自己真正了解了那个领域之后，才知道“今是而昨非”啊！
在WAR包中添加JBOSS-WEB.XML, 设置他的
/
否则访问将直接访问到ROOT.war
研究了一个多小时， 不管效率高不高， 反正搞定了！！！
无聊的一天， 躺在床上听一天收音机！
西班牙赢了希腊夺冠， 无所谓， 只要美国不赢就好， 不是讨厌美国队， 让他们认识一下自己的位置也好， 要不每次都象很“鸟”的样子，把队长的位置看的比比赛还重要， 整天吵啊吵， 这下老实了吧！！！！！
Hibernate对继承关系的对应主要有三种策略：
对每个类对应一个表： 这样在COMPANY一方不能设置SET属性； 不能进行查询， 只能对每个类进行单独的查询！ 容易在多对一的一方产生冗余数据。而且产生冗余字段(E.G Company <-- －－> Employee)
只对父类设定对应的表： 在父类内设定子类区别字段， 对每个子类特有的字段， 在父类内中都存在。 这样在父类的映射文件中， 设定Domanatrator属性， 用来制定SUBCLASS的TYPE， 子类有SUBCLASS TARGET 对应父类的DOMANATROTOR属性， 并且制定自己的属性。支持多态
缺点是不能保证数据完整性， 因为对每一个子类单独的字段， 父类的表必须允许其值为空。
对父类和子类单独见表， 用外键进行关联： 用JOIN-SUBCLASS TARGET进行外键关联， 并用KEY TARGET来指定关联属性。支持多态， 但查询用到外连接， 不易性能。
SUMMARY: 对关系数据完整性要求较高用第一种方法， 子类的独立字段不是很多用第二种方法， 否则用第三种方法。