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: 對關系數據完整性要求較高用第一種方法， 子類的獨立字段不是很多用第二種方法， 否則用第三種方法。