Ilog JRules 是最有名的商用BRMS，剛拿了JOLT；
Drools 是最活躍的開源規則引擎，一路高歌猛進；
Jess 是Clips的java實現，就如JRuby之于Ruby，是AI系的代表。

今天對比了一下這三個頗有代表性的規則引擎的規則語言。其中Ilog是商業產品，沒有機會實戰。

作者：江南白衣 

1.一樣的If--Then 句式與Rete引擎

    三者都會把原來混亂不堪的if---else---elseif----else謎團，
    拆成N條帶優先級的"If  條件語句  then  執行語句" 的句式。
   
    三者都主要使用foreward-chaining的Rete引擎，按優先級匹配條件語句，執行規則語句。
    規則執行后會引發事實的變化，引擎又會重新進行條件匹配，直到不能再匹配為止，Rete的算法保證了效率的最高。

2.開發人員使用的規則語言

2.1 Drools的XML框架+Java/Groovy/Python嵌入語言

     Drools的用XML的<Conditons>、<Consequence> 節點表達If--Then句式，而里面可以嵌入上述語言的代碼作為判斷語句和執行語句。
     其中Java代碼會使用Antlr進行解釋，而Groovy和Python本身就是腳本語言，可以直接調用。
     Drools的聰明之處在于，用XML節點來規范If--Then句式和事實的定義，使引擎干起活來很舒服。
     而使用Java,Groovy等原生語言來做判斷和執行語句，讓程序員很容易過渡、移植，學習曲線很低。

  2.2 ILog的IRL(ILog Rule Language)

        IRL用When{}Then{}表達 If--Then句式

    文檔稱IRL的語法是Java Syntax-like的，但我怎么也看不出兩者是相同的。不過他因為是商業產品，有很強大的編輯器和管理工具，編寫規則的速度應該不壞。

  2.3 Jess的CLIPS
   jess用  =>  表達 If-Then句式。 這CLIPS是真正的程序員專用語言，而且還要是很專業的程序員才習慣的東西。但這種本來就是用來做專家系統的AI語言，對規則的表達能力也應該是最強的。
   講解一下下面這段代碼，airplane有一個屬性--name，有兩個子類--噴氣式和螺旋槳飛機，其中螺旋槳飛機可以使用任意跑道，而噴氣式飛機不能使用Grass跑道。

; Fact templates     (deftemplate airplane (slot name))      (deftemplate jet extends airplane)      (deftemplate prop extends airplane) ;       Rules      (defrule can-use-grass-runway      (prop (name ?n))       =>      (printout t "Aircraft can use grass - " ?n crlf))          (defrule can-use-asphalt-runway       (airplane (name ?n))       =>       (printout t "Aircraft can use asphalt - " ?n crlf))

3.客戶使用的規則語言

   如果客戶可以自己任意編寫規則，無疑是產品一個很大的賣點。大部分客戶都會喜歡這樣一個玩具。而且也只有把規則編寫交給客戶，才能達到規則引擎的全部意義。

3.1 Drools的 DSL
     Drools的最新版Drools2.0Rc2里，House和Conways game of Live兩個例子有DSL的版本
     對比一下Java版本，效果如下：

vs

     但這種XML Base的DSL語法其實好不了多少，而且實現的代價一點不少，要自己實現Conditons和Consequence Factory類，自行解釋那段XML，基本上沒有什么便利的底層支持。
    其實，一不做二不休，干脆用Antlr來定義真正的DSL，同樣是實現Conditons和Consequence Factory類可能更好。只不過解釋XML人人都會，Antlr就比較少人用而已。

3.2 ILog的BAL(Business Action Language)--最完美的王者？
   沒有實際用過，只能看文檔過過癮。從文檔來看，配合Ilog的編輯器，的確就是很完美的規則語言了。

     JetBrains的MPS出來了，Martin Fowler也大力搗鼓出一篇《Language Workbenches: The Killer-App for Domain Specific Languages?》，成為有志于LOP、DSL領域的總領性文章。

    首先，了解Martin Fowler的立場很重要。但似乎為了保證閱讀率，MF把立場擺到了最后。

   1. LOP帶來的兩個最大優點是
      a. 通過新的封裝及思維模式，提高程序員的生產率。
      b. 改變程序員與領域專家的關系，最理想情況是領域專家直接用DSL編程。
   MF認為第2點比第1點帶來的效果大得多，但也困難得多。COBOL剛出來的時候已經有人提領域專家直接編程了，結果呢?
   
   2.現在大家對DSL應該是什么樣子的還知之甚少，文本語言?圖形語言?一切都還在假設。
   
   3.現在的LOP工具還在非常初始的階段。

   4.但MF同時認為LOP是目前最有趣的想法，不論它日后成不成功，都會激發出大量有趣的思想與實踐，留意一下LOP是絕不會吃虧的事情。

   是不是熱情驟減？本來MPS的發布使LOP看起來像是明天就可以開始動手的事情，現在又變成了雖然很有趣，但還遠沒到下山摘果子時候。
   
   從頭讀一遍文章
   1.開頭 A　Simple example of LOP
     Martin舉的這個例子占了全文1/3的篇幅，又長又不刺激神經，看得大家頻頻起身吃零食，上廁所....
　
   2.傳統的LOP
　 MDA不是什么新概念，DSL當然也用不著是，DSL其實早就在我們身邊，包括
     1.Unix下用yacc打造的微型DSL
     2.Lisp，fp用自身來構造DSL
     3.XML配置文件
     4.GUI描述文件(VB, Delphi....)
     5.Adaptive Object Models and Active Data Models? (沒完全理解)
     (注：SQL也算吧)

   3.External DSL和Internal DSL
     DSL分內外兩種，像yacc這種把DSL parser后translate成base語言的屬于External DSL。
     而Lisp這種用語言本身來構造新的語言的稱為Internal DSL。

     External DSL的好處是它可以是任何樣子的，不受Base語言的制約。另外它也通常是運行時解釋的。
     不好的地方：
     第一, 它需要花很多時間去設計語言，寫Parser，寫Generator，寫IDE。
     第二, 不能直接使用Base語言的IDE，在后IntelliJ時代這讓人很不爽.
     第三, 需要學太多語言和思維方式,不是指if-else語法的不同,而是在java里我們已經習慣了用Object和Method來表達想法,但在其他DSL里則可能要運用完全不同的概念，比如文章開頭的例子。

     而Internal DSL和External DSL的優缺點很多地方正好調轉。而且Lisp,Smalltalk的語法和我們平常的Java,C#差別很大。還有，最近Ruby們好像也有可能用來寫Internal DSL了。

     正是因為兩種DSL都缺點明確，所以DSL在今天這么不普及。Language workbeanch，正是為了使External DSL變得容易而出現的。

   4.今天的Language Workbeanch
         有Intentional Software的IP, JetBrains的MPS和微軟的軟件工廠。

         1.一段DSL將有一個Editble reprensentation，一個storage reprentsentation，一個編譯后的excuteble reprentsentation，一個在editor中的AST-Astraction reprensentation。其中editble和storage reprensentation可以合一，也可以分開。
        2.定義一個新DSL的三個步驟:
          a.定義語言的schema
          b.定義編輯器
          c.定義Generator
        一個DSL可以擁有多種編輯器和代碼生成器。
     
  5.Language WorkBench的優缺點
      優點:
       1.省卻了寫Parser，直接定義抽象語法。
       2.省卻了寫IDE。
       3.IDE的語法提示與語法檢查，給領域專家直接編寫提供了可能，這是COBOL時代沒有的。
       4.DSL與項目的良好集成，可以項目與DSL語法一起refactor，可以一邊設計語言一邊使用語言。

       缺點：
       1.Vendor專屬，用了MPS，就不可能再轉到IP或者微軟，因為他們之間根本沒有標準可言。
       2.但Generator并沒有比以前簡單（要命阿）。
       3.現在代碼以astraction reprensention為中心，版本管理，AST支持diff/merge的問題。

   6.我的立場
       試用了一下MPS，因為Generator還沒有革命性的突破，MPS還沒到真正可用的時候。
       不過幾個月間，MPS EAP已經從初始的150版本升級到220，讓人無法忽略它的進度。

     作者：江南白衣  

     注重實效的TDD的確能加快，而不是拖慢開發的進度（片面的追求覆蓋率的全面UnitTest不在此列）
      一，可以實現真正分層開發。
      二，不需要依賴和頻繁重啟Web Container。
      三，手工測試總不免改動數據庫，如何把數據庫恢復到測試前的狀態是件傷腦筋的事情。而Unit Test可以使用自動Rollback機制，巧妙的解決了這件事情。

      Spring 下的Unit Test主要關注三個方面：
       1. bean的依賴注入
       2. 事務控制，Open Session in Test 及默認回滾
       3. 脫離WebContainer對控制層的測試
      

   1.bean的依賴注入 
  能不依靠WebContainer來完成ApplicationContext的建立與POJO的依賴注入一向是Spring的得意之處。

    如果你連這也覺得麻煩，那么只要你的testCase繼承于Spring-mock.jar里的AbstractDependencyInjectionSpringContextTests，實現public String[] getConfigLocations()函數， 并顯式寫一些需要注入的變量的setter函數。
    注：因為是AutoWire的，變量名必須等于Spring  context文件里bean的id。

2.Open Session in Test 及自動Rollback
    又是來自Spring這個神奇國度的東西，加入下面幾句，就可以做到Open Session in Test ，解決Hibernate的lazy-load問題；而且接管原來的DAO里的事務控制定義，隨意定義測試結束時是提交還是回滾，如果默認為回滾，則測試產生數據變動不會影響數據庫內數據。
     你可以讓testCase繼承于AbstractTransactionalDataSourceSpringContextTests，通過setDefaultRollback(boolean)方法控制最后回滾還是提交。
 
    如果自己編寫，代碼是這樣的：

  (注，hibernate太奸詐了，如果全部默認回滾，只會在session里干活，一點不寫數據庫，達不到完全的測試效果。)

3.Controller層的Unit Test

controller層靠Spring提供的MockHttpServletRequest和Response來模擬真實的servlet環境，并且spring 2.0了加了一個AbstractModelAndViewTests，提供一些檢測返回值的utils函數。

    protected XmlWebApplicationContext ctx;
    protected MockHttpServletRequest request = new MockHttpServletRequest("GET", "");
    protected MockHttpServletResponse response = new MockHttpServletResponse();
    protected Controller controller = null;
    protected ModelAndView mv = null;
   public void setUp()
   {
        String[] paths = {"applicationContext*.xml","myappfuse-servlet.xml"};
        ctx = new XmlWebApplicationContext();
        ctx.setConfigLocations(paths);
        ctx.setServletContext(new MockServletContext(""));        ctx.refresh();
        controller = (CustomerController) ctx.getBean("customerController");
        //再加上前文的事務控制的代碼
   }
    public void testCustomerList() throws Exception
    {
        request.setRequestURI("/customer.do");
        request.addParameter("action", "listView");
        mv = controller.handleRequest(request, response);
        assertModelAttributeAvailable(mv, "customers");
    }

  
4.進一步簡化
一來這兩個基類的名字都太長了。
二來有一些公共的context文件的定義。

所以可以再抽象了幾個基類，分別是DAOTestCase，ControllerTestCase。

5. EasyMock
   MockObject是一樣徹底分層開發的好東西，而且使用上沒什么難度。而且已不再存在只支持接口不支持Class的限制。
  

   Easy Mock VS JMock:

    JMock 要求TestCase繼承于MockObjectTestCase太霸道了。妨礙了我繼承于Spring2.0的ModelAndViewTestCase和使用MockDao,RealDao并行的繼承體系。因此采用沒那么霸道的easyMock。

   另外，easyMock的腳本錄制雖不如jmock那么優美，但勝在簡短易讀。jmock那句太長了 。


6. 顯示層測試
還有，顯示層至今沒有什么好的UnitTest方法，無論是不成才的httpUnit們還是笨重的GUI test工具。Appfuse一直用的那個ThoughtWork那個Selenium和J3Unit的效果不知如何， 其中J3Unit號稱支持prototype。

     作者：江南白衣 

      以Spring為代表的提供依賴注入的IOC Container風頭越盛，比起IOC的原本意義，DI逐漸有妹仔大過主人婆的姿勢，所以Martin Fowler同學忍不住寫了篇blog，提醒一下大家IOC的本原--一種作為"所有Framework與API Library最根本的區別點"的Design Principle。
      當年侯捷同志是以VC下的MFC作例子，馬同學與時俱進，換了Ruby、Junit、SWT來教育時下的新新人類。
      IOC原理是老生常談了，可以看馬同學的blog。當應用復雜時，都應該考慮把封裝從線性調用的API級，提升到奉行IOC的Framework級。

      我更關心如何把自己的代碼交給IOC框架調用。
      1.閉包，匿名內部類，函數指針
      如果僅僅把一段代碼plug給框架，Groovy、Ruby的閉包是最簡單快捷的，再看Java中匿名內部類的做法，比如SWT的事件綁定，Spring的JDBC Template，代碼之難看令人心酸，很無妄的的要多一個接口名，一個方法名和兩層嵌套，見Martin Fowler的<閉包>的中文版.

      2.Template模式，策略模式       
      如果要把一組關聯的代碼綁定給Framework，則通常會定義出一個接口。這里的接口是廣義的。GOF里有兩種模式:
      一種是模版(Template)模式，幾種最簡單、最古老的模式之一。在父類里面定義Control flow,留下鉤子程序的位置。而在子類里實現這些鉤子程序，Junit的setup()和tearDown()就屬于這種類型。

      另一種是策略模式。Template的一個重要制約為兩者必須是父子關系，這對于單根繼承的java有點不便。另外，策略模式在靈活性上顯然更勝一籌。策略類只需要實現某個接口，容器就可以在適當時進行調度。比如EJB，和Swing都是這種模式。

      3.消息綁定
      最后，MS家還有個更高明的消息機制，可以實現更靈活的綁定。

      4.AOP, cglib和Annotaton
      另外，馬同學沒有講的，因為AOP和元數據的出現，框架本身又有了新的封裝方式。
      框架可以用AOP更隱式，無侵入的提供服務，Annotation可以更簡潔的告訴框架如何提供服務。

      比如Spring 的JDBC Framework ，封裝了連接，事務，異常的管理，讓你可以專心的寫SQL查詢。但那些個匿名內部類讓你怎么看怎么不爽，而Java又的確沒有閉包......這時你可以用Spring的聲明式事務管理機制，你只要把業務代碼寫成普通函數，而Spring會利用AOP隱式的包裹你的代碼提供連接、事務的管理。

      如果你不喜歡用xml配置文件聲明事務，可以自己用cglib+annotation簡單實現一下。甚至，如果你連 annotation也不喜歡，還可以學習rails, 用純命名約定搞定，只在必要時采用annotation輔助。

     潮流興用Ruby寫Sample Code.   
     還有一樣事情，就是馬同學開始喜歡用Ruby來寫sample code。發現Ruby寫sample code的確好，讀的時候像偽代碼一樣清晰簡單，寫的時候也可以一氣呵成，沒有太多無聊定義與制約，也不用怕別人投訴代碼編譯不了....

   它的好處有一打，比如為所有項目提供共同的Library Stack，提供最可靠的代碼藍本，保證大家的模式和代碼風格一致，加快知識在團隊的傳播，方便新人的融入，還有為試驗代碼提供一個穩定簡潔的環境。

   所以，一個長期合作的團隊，需要這樣一個MyAppfuse。

   但還要有三條鐵的紀律，才能保證辛苦做出來的MyAppFuse不是個寂寞的芭比。
   一是強制更新，所有團隊approval的最新模式都要refactor到MyAppfuse中。
   二是規范更新，每次更新都要嚴格測試并編寫更新記錄、移植文檔。
   三是強制Copy Start，所有代碼都必須從MyAppFuse里Copy而不是隨自己喜歡找任意項目的代碼。

   現在開始規劃一個Appfuse式項目。我覺得包含如下Content：
   1.設計典型的應用情景。
       我平時的ERP項目，最典型的情景莫過于：
       *基礎資料管理（如產品資料的CRUD)
       *單據管理（如訂單的錄入與管理）
       *典型報表

       每個場景應該有簡單與復雜兩種模式，方便Developer選用。
       場景要仔細設計，盡量演示到所有重要的技術要點。
       但場景又要盡量的少，盡量簡潔，減少每次模式升級的成本。

   2.挑選出其他比較重要的特性。
        如Quartz、ClickStream，也一并放入MyAppFuse中。

   3.把所有用到的框架、類庫、瓶瓶罐罐統統打包。
       并附上索引和說明作為團隊公用的Library Stack，每次library升級都要認真檢測。

   4.編寫文檔。
        類似Appfuse的Tutorial，編寫文檔說明各個場景用到的技術要點與模式，說明如何二次開發。
        類似Appfuse的Migrate，詳細說明如何升級到MyAppfuse新的版本，促進新模式的傳播。

   5.簡單代碼生成工具。
       類似Appfuse的AppGen，用Groovy Template或FreeMarker編寫簡單的代碼生成模版。

   6.核心的測試用例

    后記:這個MyAppfuse終于開源成http://www.springside.org.cn

    作者：江南白衣 

     ANTLR(ANother Tool for Language Recognition)風頭正盛，經常可以看到用它做語法解釋器的項目，比如Hibernate就在3.0換上它來解釋HQL，加強了HQL的語法。
     因為Antlr是EBNF-AST語法解釋系的代表，而自己總是心思思想搞一下DSL(領域語言)，所以從Hibernate來學習一下Antlr的應用。

     Hibernate HQL translator作者Joshua Davis的兩個Blog
     Hibernate3 Query Translator Design - Part One : The Basics
     Hibernate3 Query Translator Design - Part Two : Parsing HQL

     Antlr最好的介紹文章是那篇，在《程序員》２００４年３月有中文的版本。  不過，那個計算器的例子太簡單了。深刻一點的有。
     另外，SlickEdit 支持Antlr的語法，是一定要用的編輯器，在 ttdown.com上有破解。

　　一，Antlr引擎的工作過程大概是這樣的：
　　1.Lexer類--詞法分析器。 
        定義語言中的各種Token(單詞)，如 From 、Where、=、<>.......
        Lexer負責把讀入的普通文本流識別成Token串。

　　2.Parser類--語法分析器。
        使用BNF語法，遞歸定義句子的Pattern，如whereStatement、FromStatement、SelectStatement。
　　   Parser負責把讀入的Token串匹配成句子，翻譯出AST(抽象語法樹)。
　　   有些簡單的應用，也可以在本層現炒現賣，完成所有動作，屬于Single Pass Builder。

　　3.TreeParser類--抽象語法樹遍歷器。
        根據Parser類分析出來的AST(抽象語法樹)進行動作。
           
        用Parser把AST抽取出來，再用TreeParser進行動作的Double Pass Builder模式，解耦了Parser和Generation，再配合Template 生成代碼，是Antlr推薦的最佳模式。

　　二，開發人員的實際步驟

　　1.按照Antlr的簡單語法定義前面講的３個類，文件的后綴名為g。

　　2.使用java antlr.Tool xxx.g 命令，把grammar文件編譯成java文件。

　　3.編寫應用程序，如:

    三，Hibernate對Antlr的應用
     看過Antlr對HQL的解釋，覺得EBNF系的方法要解釋Java這樣的編程語言還好些，如果要解釋類自然語言的DSL就比較痛苦，所以情緒不是很高漲，挑一條最容易的"Delete from goods where ....." 匆匆走過場

   Joel的一句話對我的影響比較大："如果為了證明一個微不足道的問題需要花三個小時寫下幾黑板的證明步驟，那么這種機制不可能用來證明任何有趣的東西" 。對于我這個層次的程序員，antlr在我手中造不出有趣的DSL來。

   Hibernate的HQL Grammar文件一共有三個，在/grammar目錄下:
   1.hql.g   定義Token類和Parser類，將HQL解釋成hql的抽象語法樹(AST)
   2.hql-sql.g  定義Tree Walker ，將HQL AST轉化為SQL AST，將生成模塊與Hibernate解耦。
   3.sql-gen.g 定義Tree Walker，從SQL AST生成sql

   下面看 DELETE FROM GOODS的翻譯過程

   1.HqlBaseLexer extends Lexer
      定義EQ: '=';  LT: '<';  GT: '>';PLUS: '+';等符號
      及IDENT: ( 'a' .. 'z' | '_' ) ( 'a' .. 'z' | '0' .. '9' | '_' | '$' )*

   2.HqlBaseParser extends Parser
      先定義DELETE="delete"; FROM="from"; MIN="min"; 等字符串
      再定義:

     3. HqlSqlBaseWalker extends TreeParser  
         hql與sql的delete語句基本上是一樣的，沒什么轉換。

     4.SqlGeneratorBase extends TreeParser
          
         根據SQL AST, 生成SQL語句         

 private StringBuffer buf = new StringBuffer();
          protected void out(String s) 
          {
                buf.append(s);
          }

          statement
          : selectStatement | updateStatement | deleteStatement
          ; 
         deleteStatement
         : #(DELETE { out("delete"); }
               from
              (whereClause)?
             )
         ;輸出"delete"          from
          : #(f:FROM { out(" from "); }
           (fromTable)* )
                    fromTable
         : #( a:FROM_FRAGMENT  { out(a); } (tableJoin [ a ])* { fromFragmentSeparator(a); } )
         | #( b:JOIN_FRAGMENT  { out(b); } (tableJoin [ b ])* { fromFragmentSeparator(b); } )
         ;         tableJoin [ AST parent ]
          : #( c:JOIN_FRAGMENT { out(" "); out(c); } (tableJoin [ c ] )* )
          | #( d:FROM_FRAGMENT { nestedFromFragment(d,parent); } (tableJoin [ d ] )* )
         ;

         .暈了吧 ~~~~~
         whereClause
          : #(WHERE { out(" where "); } ( conditionList | booleanExpr[ false ] ) )
          ;

(除了EL里面不能調用goods的函數，sun那幫老頑固始終堅持JSTL只能用于數據顯示，不能進行數據操作，所以不能調用bean的get/set外的方法)

 2. 最懶的form 數據綁定

    Spring少得可憐的幾個tag基本上是雞肋，完全可以不要。 而Spring開發中的那些Simple Form tag又還沒有發布。Spring的Tag主要用來把VO的值綁到input框上。但是，和Struts一樣，需要逐個Input框綁定，而且語法極度冗長，遇到select框還要自己進行處理.....典型的Spring Sample頁面讓人一陣頭暈.

    而jodd的form tag給了我們懶人一個懶得多的方法，只要在<form>兩頭用<jodd:form bean="myVO"></jodd:form>包住，里面的所有input框，select框，checkBox...統統自動被綁定了，這么簡單的事情，真不明白struts,spring為什么不用，為了不必要的靈活性么?

<input name="customer.customerNo">

這是因為它的beanUtils比Jakata Common弱，用了一個錯誤的思路的緣故。 動用beanUtils修改一下就可以了，修改后的源碼可以在這里下載。

3. DataGrid數據列表

DisplayTag和ValueList都屬于這種形式的Tag Library。但最近出現的Extreme Table是真正的killer，他本身功能強大不說，而且從一開始就想著如何讓別人進行擴展重載，比如Extend Attributes機制就是DisplayTag這樣的讓千人一面者不會預留。


4.css, javascript, ajax
天下紛擾，沒有什么特別想講想推薦的，愛誰誰吧。Buffalo, DWR, Scriptaculous, Prototype, AjaxTags, AjaxAnywhere, Rico, Dojo, JSON-RPC，看著名字就頭痛。

相關文章
簡化Spring(1)--配置文件
簡化Spring(2)--Model層
簡化Spring(3)--Controller層
簡化Spring(4)--View層

作者：江南白衣 
   
                           序

    人人都愛Spring加Hibernate。
    但Spring MVC+hibernate的Sample如Appfuse的代碼卻算不得最簡潔優美好讀，如果在自己的項目中繼續發揮我們最擅長的依樣畫葫蘆大法，美好愿望未必會實現。
     所以，Pramatic精神不滅。這個系列就是探尋最適合自己的Spring+Hibernate模式。
    
                              I-配置文件簡化

     我厭倦一切配置文件繁重的框架。
     最好的情況是，框架提供極端靈活復雜的配置方式，但只在你需要的時候。
 
     Spring提供了三種可能來簡化XML。隨著國內用戶水平的提高，這些基本的簡化技巧大家都已掌握。
     大家可以直接看第3，第4點--Spring 1.2, Spring 2.0的后繼改進。

1.1.autowire="byName" /"byType"

     假設Controller有一個屬性名為customerDAO，Spring就會在配置文件里查找有沒有名字為CustomerDAO的bean, 自動為Controller注入。
     如果bean有兩個屬性，一個想默認注入，一個想自定義，只要設定了autowire，然后顯式的聲明那個想自定義的，就可以達到要求。這就應了需求，在需要特別配置的時候就提供配置，否則給我一個默認注入。

     還有一個更懶的地方，在最最根部的<beans>節點寫一句default-autovwrie="byName"，可以讓文件里的所有bean 都默認autowrie。
    不過Rod認為開發期可以這樣，但Production Server上不應該使用Autowire。而我覺得那些自定義一次的地方比如TranscationManager應該詳細定義，而Dao,Controller這種大量重復定義的bean就可以偷點懶了。

1.2.<bean>節點之間抽象公共定義和 Inner Bean

    這太方便懶人了，想不到兩個獨立的XML節點都可以玩繼承和派生，子節點擁有父節點的全部屬性。
    最好用的地方就是那個Transtion Proxy的定義。先定義一個又長又冗的父類，然后用子類去繼承它。
   
    另外，還有一個Inner Bean的機制，可以把DAO寫成Proxy的內部類。為什么要寫成內部類?為了讓Proxy冒名頂替它去讓Controller Autowire。(詳見后面的示例)

1.3. 寬松的配置, To XML or Not to XML 
    據說Spring比Struts的配置寬松了很多，這就給人把東西從配置文件中撤回原碼中的機會。
    不贊成什么都往配置文件里曬，造成了Rich Information的配置文件，修改或者查看的時候，要同時打開配置文件和原碼才能清楚一切。
    而我希望配置文件就集中做一些整體的配置，還有框架必須的、無需管理的冗余代碼。而一些細節的變化不大的配置和邏輯，就盡量別往里塞了。因此，Success/Fail View 的配置，不建議放在里面。

2.簡化后的配置文件

1.Controller只剩下一句

2.DAO也只剩一句

3.Service類只剩下5行

3.Spring 1.2后xml語法簡化

 最主要的簡化是把屬性值和引用bean從子節點變回了屬性值，對不喜歡autowire的兄弟比較有用。
 當然，如果value要CDATA的時候還是要用子節點。另外，list的值可以用空格隔開也比較實用。

1.屬性值

  <property name="foo">
     <value>fooValue</value>
  </property>
  簡化為
  <property name="foo" value="fooValue"/>

2.引用 bean

<property name="foo">
   <ref bean="fooBean">
</property>
簡化為
<property name="foo" ref="fooBean"/>

3. list可以簡化為空格分開的字符串

 

<property name="myFriendList">
  <list>
     <value>gigix</value>
        <value>wuyu</value>
  </list>
</property>
簡化為
<property name="myFriendList" value="gigix wuyu"/>

   
  
4.Spring 2.0來了
   如果沒什么外力刺激，spring xml 可能就這樣不會變了。但現在xml成了過街老鼠，被ror的默認配置和JDK5的annotation逼得不行，當然就要繼續求變。
   比如有好事者認為，節點名必須以bean打頭，附加一個屬性id來表示bean名；屬性值必須搞一個property子節點，子節點上有個屬性name來表示屬性名，是給機器看的很不直觀的東西。

<bean id="customerDAO" class="org.springside...CustomerDAO">
 <property name="maxCount" value="10">
</bean>

給人看的東西應該就寫成

<customerDAO class="org.springside....CustomerDAO" maxCount="10"/>

Spring 2.0正用schema實現類似的語法，具體請看它的JPetStore sample。

    如果沒有用Eclipse的Spring插件，那至少也要使用spring自帶的dtd使XML編輯器smart一些，能夠自動為你生成屬性,判斷節點/屬性名稱有沒有拼錯等。

6.還有更變態的簡化配置方法
    比如autoproxy，不過我覺得更簡化就不可控了，所以沒有采用。

相關文章
簡化Spring(1)--配置文件
簡化Spring(2)--Model層
簡化Spring(3)--Controller層
簡化Spring(4)--View層

作者：江南白衣 

1.Groovy的最新八卦之處
1.1 Wiki： http://docs.codehaus.org/pages/listpages.action?key=GROOVY
1.2 Mail list的在線瀏覽和rss定閱 
       Developer List http://dir.gmane.org/gmane.comp.lang.groovy.devel
       User List: http://dir.gmane.org/gmane.comp.lang.groovy.user

2.Groovy的開發現狀和未來
    編譯期健壯性大大增強的1.0 JSR-2，全力除Bug的1.0 JSR-3，JSR-4已經發布。
    第二次全球Groovy 開發人員FB大會也在巴黎開完，有決議若干。
    理論上 1.0正式版很快就要發布。 
    而計劃中的1.1版本將支持 ruby的maxin、continuations 和JDK1.5的Annotatin。

3.Groovy and Java的曖昧關系
   作為Java的私生子，Groovy的最終可執行狀態是Java class bytecode，所以Java代碼里可以把它當普通Java Bean一樣調用。還有，Groovy的基礎類庫，都是用Java代碼來寫的。

   3.1 編譯Java class bytecode
   就像JSP的最終面目是servlet class，GroovyC也會把groovy文件編譯成Java class bytecode以在JVM上運行。
   其中Groovy Class會編譯成GroovyObject的子類，Groovy Script代碼段會編譯成Script的子類。
     
    可以用GroovyC來靜態編譯，也可以在Java程序里用GroovyShell動態parse Groovy文件。

    3.2 在Java代碼中調用Groovy
         1.Groovy類：
         GroovyObject類默認有get/setProperty()和invokeMethod()的反射接口，在Java代碼里，可以直接調用Groovy類的方法，也可以通過反射接口來調用。

         2.Script代碼段：
         Script類有Script(Binding)構造函數和run()接口，在java里先通過Script(Binding)構造一個Script類，綁定變量，然后通過run接口進行調用。

    3.3 在Java中直接使用Groovy的類庫
    Groovy和Groovy的框架類庫都是用Java寫出來的的。所以有些類庫如SimpleTemplateEngine，也可以在Java里直接使用，不用繞Groovy一圈。

4.groovyJ插件
    groovyJ是IDEA插件，有語法變色和Run()功能，更有用的功能是編譯Java文件目錄時，會把其中的groovy文件也一同編譯。而日后將支持重構、類間跳轉等功能，值得期待。
    而Eclipse插件只有Run()和語法變色，而且隨著Eclipse的升級時靈時不靈，正在花時間實用化中。
    NetBeans開了個Coyote的項目來支持腳本語言。

5.一些重要的開發人員 
    一個PM：
    Guillaume Laforge

    兩個Founder：
    Bob Mcwhirter (同時是Drools，Dom4J的founder) ，
    James Strachan (Core Developers Network，同時work on Geronimo,Drools,ServiceMix 和很多Jarkarta 項目，似乎擁有無窮的精力)    

    三個來自ThoughtWorks的開發人員：
     Jame Walnes，Chris Stevenson，Matt Foemmel

    四個star of  JSR-2: 
     Jeremy Rayner, Jochen Theodorou，和兩位老大一起改進JSR-2編譯的強壯性和出錯信息顯示 
     Franck Rasolo：IDEA插件GroovyJ的開發人員 
     Christian Stein ：Groovlet,Template的開發人員 

     Steven Devijver : Grails--Groovy on Rails的主持，同時是Spring Modules的leader。

6.有哪些使用Groovy的項目

Grails(Groovy on rails,大老們非常期待的項目，把rails在MVC和ORM的優點抄到java下，而且是基于Spring Framework的)

Drools(規則引擎, 用戶可以用groovy寫規則)

eXo platform(porlet/Service container，本身核心是groovy，用戶可以用groovy 來寫Porlet)

XWiki (第2代的wiki引擎、Application引擎。用戶可以用groovy寫Plug-in，Marco和Application)

RIFE(一個MVC/Web framework，用戶可以用groovy寫action和配置layout,workflow。還含有一個CRUD框架，用戶用groovy 定義domain class，滴嗒一下，就能獲得一個CRUD模型)

7.Groovy-all-1.0-jsr3.jar 
    groovy需要asm和antlr包的支持，使用groovy-all-10-jsr3.jar，將預帶這兩個包的正確版本，非常省心。

8.Migrating to JSR
    JSR版本語法的的最大改動有兩處。網上很多Groovy文章都還是基于舊語法的，需要自己改正過來。
    8.1 為了加強代碼健壯性，Class里的變量需要用def 定義。而在script里的變量因為是動態binding的，仍然不需要def定義。

    8.2 多行的String需要用 """ """而不是" "來括住。

9.SimpleTemplateEngine-總共200行就實現了JSP engine的功能
    動態語言開發框架很方便，所以Ruby on Rails沒有IDEA級的IDE都能這么就把MVC、ORM都實現了一遍。
    請看src/groovy/text/SimpleTemplateEngine.java，總共219行。
    原理就是把模版中的文本部分替換成println """ 文本""" ，Groovy部分照搬，生成一個新的Groovy script，然后拿GroovyShell執行一遍就完成了。

10.如何用Java實現動態語言

　把GroovyC編譯出來的class文件再用jad反編譯，可以看到如何用Java去實現一門動態語言。
    主要是多了一個MetaClass,　不斷的反射反射，運行時還非常依賴Asm

　最簡單的例子:
   Groovy文件:

 public class Customer
 {
    private String id;
 } 

   編譯出來的Java文件

   public class Customer    implements GroovyObject 
  {
　　 private String id;
　　 transient MetaClass metaClass; 
　　 public Customer()
        {
            Object obj = ScriptBytecodeAdapter.invokeStaticMethod  ("org.codehaus.groovy.runtime.ScriptBytecodeAdapter", "getMetaClass", this);
            Metaclass　 metaclass = (MetaClass)ScriptBytecodeAdapter.asType(obj, groovy.lang.MetaClass.class); 
        } 
       public Object invokeMethod(String s, Object obj)    {} 
       public Object getProperty(String s)    {.}

    作者：江南白衣 

    前篇:〈在Spring+Hibernate框架下，用動態語言寫業務類〉講述在Spring+Hibernate的架構下，因為動態語言所帶來的利益，把一部分業務類改用Groovy編寫并編譯成Java Class文件。
    而且，因為Groovy的強大與簡便，加上與Java親密無間的關系，一些框架類也可以逐漸考慮用Groovy編寫。

  1.雖然多是星零的好處，但忽然間一整噸好處擺在面前還是很讓人感動的。

    除了動態語言和閉包、MOP，Groovy其他的特性多是對J2SE中設計不合理的地方逐一進行修正，集合、IO、字符串操作......雖然多是星零的好處，但忽然間以整噸好處擺在面前還是挺讓人感動的。 

   同時，Groovy完全兼容Java語法，但又提供糖糖選擇的方式感覺很貼心。(Groovy唯一不支持的java語法就是Inner Class的定義和函數定義里的"throws Exception" , 私生子的好處啊)

    隱約覺得因為動態語言的無類型，還有閉包這樣帶著Lisp式FP的印記，加上MOP這樣的機制，可能會激發更大的變革發生。

1.動態類型
   動態類型在Framework型項目中非常重要，多少設計模式嘔心瀝血，就是為了和這個類型搏斗。
   而且，如果你是把代碼編譯成java Class，健壯性不會減低太多。
 
2.閉包
    fp的基礎，沒有閉包的C++用函數指針，java用匿名內部類，都比他差遠了。
    詳看Matin Flower <閉包>文章的中文版 ，在一段文件操作的Script中試演了一下，果然使代碼簡潔了好些。

3. MOP
    Groovy的Team Leader-- Guillaume Laforge最喜歡的一樣特性，groovy 嵌入式XML語法的基礎，對屬性和方法訪問的intercept 機制。詳看另一篇blog。
     又比如，在MOP下，DAO那一堆findByName,findByTitle不用再逐一實現了，實現一個findBy即可攔截其他子虛烏有的findByXXX。

4.   b.hql 可以多行，不用寫N多"和+ ， 寫sql時特別方便。
   c.簡單集成了正則表達式
       If ("name"==~ "na.*")
           {println "match!"}

  //自動生成Getter和Setter
   class Customer 
   {
      Integer id;
      String name;
   }   
    //簡便的對象賦值
   customer = new Customer(id:1, name:"calvin");
   customer2 = new CUstomer(id:2);

   book = new XmlSlurper().parseText("<book writer='calvin'><title>D</title></book>")
   println book.title;
   println book[@writer];
   println book.children().size();

package com.itorgan.myappfuse.dao;
import org.springframework.orm.hibernate3.support.HibernateDaoSupport;
public class CustomerDAOGroovy  extends HibernateDaoSupport
{
    public insert(customer)
    {
        getHibernateTemplate().save(customer)
    }

    public List getAllValid(sortColumn)
    {
        def  hql = """from Customer customer
               where customer.status='valid'
               order by ${sortColumn}"""
        def query = getSession().createQuery(hql)
        return query.list()
    }

    public boolean isUnique(customer, uniqueColumnNames)
    {
        def params = []
        def hql = "select count(*) from Customer customer  where  "
        def first = true
        uniqueColumnNames.tokenize(",").each
        {
            if (!first)
                hql += " or "
            else
                first = false
            hql+="customer.${it}=?"

            params << customer.getAt(it)
        }
        def result = getHibernateTemplate().find(hql,params.toArray())
        return ( result.get(0) == 0)
    }
}