隨筆分類(103)

    昨天看到《精通EJB3.0》的中文版出來了，雖然早就在預(yù)料之中了，不過多少還是有一點想法的，終于第一本 EJB 3.0 的書正式出來了，對目前 EJB 3.0 的追逐總歸是有了點方向，但我仍然感覺，EJB 3.0 不可能像 EJB 2.0 那樣火了，Java 世界已經(jīng)進入了多元化時代，Spring 已經(jīng)逐步的蠶食了 EJB 說占有的份額，用其簡單靈活的配置吸引了無數(shù)人的眼光，從另外一方面來說，標準的東西畢竟是標準，從制定到實現(xiàn)的周期比較長，如果中間出現(xiàn)了新的需求，一些問題，都需要等到下一個標準中去實現(xiàn)，而開源的就比較靈活了，有問題可以隨時調(diào)整，所以會帶給大家更為 agile 的感覺，不過對于大公司大項目而言，他們并不希望這樣的靈活性，他們需要的是風(fēng)險小，穩(wěn)定，所以 EJB 3.0 對于一些大型的企業(yè)應(yīng)用來說依然需要的是 EJB，因為有 IBM 和 BEA 這樣大公司的支持了，不過自從五月份 JavaEE 5 規(guī)范正式定稿，這兩大公司都沒有拿出真正的 EJB 3.0 的產(chǎn)品出來，倒是 JBoss 在標準出來后很快就拿出了可用的產(chǎn)品，這樣也可以看出來，IBM 和 BEA 沒有像過去幾年對于 EJB 2.0 那樣的重視了，他們關(guān)注的是 SOA 的市場，畢竟 SOA 在 EAI 方面比 JavaEE 強了很多。

    對于分布式對象領(lǐng)域，EJB 3.0 還是有著不錯的競爭優(yōu)勢的，畢竟這是他的傳統(tǒng)優(yōu)勢，在群里面和大家聊天的時候，寒江也提到過用 RCP + EJB 3.0 作為方案，其實這也是一套不錯的應(yīng)用方案。

    EJB 3.0 比 EJB 2.0 確實要輕了很多，但并沒有給我們太多的驚喜，因為 EJB 3.0 給我們帶來的大部分新鮮都已經(jīng)被 Spring 和 Hibernate 捷足先登了，我個人也是比較喜歡 Spring 和 Hibernate 來做項目，畢竟用起來會更加的靈活，更加的強大，特別是新版的 Spring 和 Hibernate 同時都支持了 JPA 的標準，又一次的在 JavaEE 應(yīng)用上和 EJB 3.0 展開了下一輪的競爭，一切都好，就看你怎么選擇，我選擇的是 Spring + Hibernate，或許更加熟悉一些又或許更加輕量，更加 agile。

    一直從dearbook創(chuàng)辦起就在 dearbook 買書直到現(xiàn)在，已經(jīng)成為了鉆石VIP會員了，經(jīng)歷了 dearbook 發(fā)展中的種種，不過說起來 dearbook 的服務(wù)確實不像其標語中說標榜的"第二書店，第一服務(wù)"，從我這么多年和他們打交道的經(jīng)驗來說，服務(wù)確實很難讓人滿意。

    過去一開始的時候，都是采用在網(wǎng)上選書，然后郵局匯款，發(fā)郵局包裹的方式，效率很低，也很麻煩，每次總是要往郵局跑兩次，最大的問題是，網(wǎng)上列出來的書，往往是不一定有貨的，有一次買書，選了一堆書最后發(fā)現(xiàn)就一本書有貨，最后拿到手的只有那一本書，很是郁悶，這樣就余下了一些錢在 dearbook，然后又用這些錢繼續(xù)去買其它的書，最后在升級會員的時候，這些余款購買的書又沒有記入積分中，升級的時候就差了這么幾分，最后催了好幾次才把自己會員資格提高。

    隨著和當當網(wǎng)合作以后，付款和收貨方面確實有很大的改善，付款直接用網(wǎng)上銀行，直接送貨上門，都大大的提高了我買書的興趣，不過 dearbook 網(wǎng)站系統(tǒng)很不爭氣，頻頻出現(xiàn)問題，首先發(fā)現(xiàn)一個明顯的 bug 就是在收藏夾里刪除一些書籍的時候，收藏夾就變亂了，都是一些莫名其妙的書，再打開一下這個頁面就好了。接著是在和 CSDN Passport 整合的時候，收藏夾里的書徹底丟光了，而這時候沒有人告訴我怎么回事。

    在與當當網(wǎng)的合作中dearbook 的積分系統(tǒng)也頻頻出現(xiàn)問題，當當網(wǎng)是用 Email 賬戶登錄的，dearbook 積分系統(tǒng)也是用 Email 賬戶登錄的，當我修改了當當網(wǎng)的 Email 以后，dearbook 積分系統(tǒng)也換成了新的 Email，但原有 Email 對應(yīng)積分沒有轉(zhuǎn)到新的 Email 帳號上來，打電話去問，答曰，沒有提供合并積分的功能，于是一堆積分就泡湯了。

    最近積分比較多，在 dearbook 換了兩本書，最后收包裹的時候，只收到一本書，覺得奇怪，打電話去問，才把第二本書給重新寄過來，浪費了我?guī)追昼姷碾娫捹M。

    這次 dearbook 又心血來潮的要把 D幣積分轉(zhuǎn)換為 C 幣，因為過去在兩個Email 賬戶上都是有積分的，所以想轉(zhuǎn)換到同一個賬戶上，結(jié)果當我在 CSDN 上修改了 Email 地址后，卻發(fā)現(xiàn)我過去的積分就消失了，很是郁悶。昨天發(fā)了郵件，今天打了電話，到現(xiàn)在也沒有人給我答復(fù)，看了一下賬戶里的 C 幣，還是不對。

關(guān)于敏捷問題

周末聽 rocket 介紹了一些來自 thoughtworks 關(guān)于敏捷的一些思想，同時也引發(fā)了大家的一些思考和討論。從一種角度來看， Agile 體現(xiàn)了一種軟件開發(fā)最根本的問題，就是由人在一定的時間內(nèi)開發(fā)出高質(zhì)量的軟件，Agile 更加注重人在整個活動里的作用，而傳統(tǒng)的瀑布模型中，似乎更加注重文檔等，也就是我過去所在的公司，一切開發(fā)都由文檔驅(qū)動，在這樣的情況下，團隊中每個人都是可以被替代的，從某種意義上來說，降低了軟件開發(fā)的風(fēng)險，但是效率卻很難提高。而 Agile 注重的一個方面就是 pair，通過拉近人與人之間的具體來加快信息在團隊中的流轉(zhuǎn)速度，使信息像水流一樣源源不斷的流動，這樣在 change 發(fā)生時，能夠得到更快的響應(yīng)，而瀑布模型則需要慢慢的由文檔傳播開來，傳遞速度和面都比較有限。

雖然 thoughtworks 給了我們一個極具誘惑的 Agile 果子，某種意義上來說是建立在他們公司利益基礎(chǔ)上的，真正的去做 Agile 需要更加清醒和理智的想問題。Agile 是一種實踐的方法論，需要大量實踐和經(jīng)驗才能真正的去理解它，另外一方面，從傳統(tǒng)的開發(fā)方式轉(zhuǎn)型至 Agile，多多少少都會有過去殘留的痕跡，而這些看不見的痕跡，可能會暗暗的抹殺 Agile 最初承諾的效果。

Agile 是一種好東西，某種意義上，資本家從開發(fā)人員手里榨取了更大的價值，這是建立在效率提高基礎(chǔ)之上的，但它卻散發(fā)著無比的誘惑，或許大家希望自己少寫一些文檔，或許大家厭倦了瀑布模型的流程，或許。。。。

    這里我們要將 Tapestry 與其它主要的 Java Web 框架做一番比較，包括 Struts，JSF。

    Struts 是一個 Action 方式的 Web 框架，所有的請求直接對應(yīng)了相應(yīng)的 Action，我們需要通過一些相應(yīng)的技巧性處理才能把我們在頁面上的 Click，Value Change 等轉(zhuǎn)換到后端對應(yīng)的 Action，抽象程度顯得不夠高，并且這樣會使 Struts 在處理一些較為復(fù)雜的頁面時配置過多，造成開發(fā)和維護上的繁雜。另外 Struts 默認使用的 Tiles 模板框架使用了 <jsp:include> 方式的拼裝頁面技術(shù)，并且在每個頁面都需要配置，這樣的話，又增加了不少的配置量。在Struts中，經(jīng)常需要使用標簽庫通過 EL（Expression Language）來顯示組件ActionForm中內(nèi)容，這就涉及到一個結(jié)合的問題，標簽庫是別人寫的，而且 Struts 在這方面并沒有確定的標準，如何才能讓自己的組件庫和現(xiàn)有的組件庫很好的結(jié)合，難度和麻煩就體現(xiàn)在這個結(jié)合點上。

    JSF的視圖層開發(fā)的基本思路和Struts差不多，只不過換了不同標簽庫，也需要標簽庫+組件的結(jié)合思考，不過因為組件這里是通用組件，沒有什么限制，并且遵循了一個共同的標準，所以這樣比Struts要輕松一些。JSF 提供了一套完整的生命周期和組件標準，我們很容易的為其定制一些組件和使用現(xiàn)有的組件庫。另外JSF采用了事件驅(qū)動的方式，同一個頁面對應(yīng)的多個 Action 請求會比較直接的通過 EL映射到后端對應(yīng)的 Java 方法上，從而大大減少了復(fù)雜頁面的配置量。但是在默認情況下，JSF 每個頁面的都需要配置其單獨的導(dǎo)航，如果頁面導(dǎo)航復(fù)雜的話，配置還是不少的。JSF 在默認情況下并沒有集成模板引擎，但是開源的 Facelets 模板引擎提供了類似 Tapestry 的模板方式，從另外一種方式簡化了 JSF 的開發(fā)。JSF 采用了 HTML 頁面保存組件樹的機制，頁面的所有組件和組件狀態(tài)被序列化到頁面中或者 Session 中，這樣的話，如果在頁面上 Javascrīpt 通過修改 DOM 的方式修改頁面的組件，會導(dǎo)致頁面和組件樹不一致，導(dǎo)致 JSF 無法正常工作，但是可以通過 Ajax 方式向服務(wù)端發(fā)出更新組件樹的請求，但這樣需要走完 JSF 整個生命周期，顯得較為笨重，所以從架構(gòu)上來看，JSF 在處理頁面問題上不夠靈活，也不夠 Ajax 化。

    Tapestry使用了組件庫的概念替代了標簽庫，沒有標簽庫概念，這樣就沒有標簽庫和自己的組件需要結(jié)合的問題，都是組件的使用，組件中分Tapestry標準組件和自己定義的組件，這也是接觸了JSP體系的人學(xué)習(xí)Tapestry面臨的一個思路轉(zhuǎn)換。這樣極大的減小了頁面修改而帶來的修改難度。同為事件驅(qū)動的框架，在配置上 Tapestry 有著和 JSF 類似的優(yōu)勢，我們只需要簡單的在 XML 文件里配置事件和后端方法的對應(yīng)關(guān)系，或者使用 OGNL 直接在頁面中與后端方法建立關(guān)聯(lián)。在頁面導(dǎo)航上，Tapestry 是根據(jù)監(jiān)聽器方法的返回值而確定，這樣就省去了頁面導(dǎo)航部分的配置。Tapestry 的模板技術(shù)天生就是其優(yōu)勢所在，這樣的方式將前臺頁面的制作和后臺業(yè)務(wù)系統(tǒng)的開發(fā)完美的結(jié)合在一起。Tapestry 因為沒有 JSF 這樣的組件樹綁定的方式，就能夠比較容易的和 Ajax 綁定在一起，目前開源的 Tacos 組件庫就提供了很多這樣的組件，并且整合了 Dojo Toolkit 使得我們開發(fā)頁面中有了更多好用的組件，并且只需要很簡單的配置工作就可以使用功能強大的 Web 組件和 Ajax 功能。

    另外，JSF/Tapestry不只是支持HTML，也支持多種客戶端語言如WML或XUI等。

    雖然看起來兩者似乎沒有什么聯(lián)系，但是看起來 工作流 的一些概念和狀態(tài)圖有著驚人的相似之處，或許是我過去對 UML 的理解太少了，而對 UML 的理解有僅限于 Class Diagram 和 Sequence Diagram，而且僅僅是一些粗淺的認識，而在和 Sze Hung 老大以及 james 討論問題的時候，也經(jīng)常遇到狀態(tài)機的概念，或許是我在這方面太過于薄弱了。今天在 dearbook 定的 UML User Guide 2nd 也到了，這本凝聚了 Rational 三巨頭的心血之作中貫徹著這樣的思想。希望能夠從中吸取更多精華吧。

    很多粗人都常常認為 UML 只是畫圖的東西，三兩頁就可以講完的東西，何必弄這么多呢，還印出 n 多本書，簡直就是騙錢了。其實說來，UML 難道僅僅是一種圖形工具嗎，它凝聚了更多更深刻的 OOP 的概念，在各種各樣的應(yīng)用中才發(fā)現(xiàn)，原來 UML 比我開始想想的要豐富的多。

    看過一些人在網(wǎng)上的評論，才發(fā)現(xiàn)，其實人民郵電出版社和機械工業(yè)出版社的書其實并不是太差了，只是機械的紙實在是說不過去，在我書架上放的一堆書中，原來清華大學(xué)出版社的書是最差的，無論從紙張，從排版，從翻譯，因為有康博這樣被罵死也還要出來招搖撞騙的所謂翻譯團隊。近些年來，一些出版社都開始建立了一些自己的圖書品牌，比如說電子工業(yè)出版社的“博文視點”，比如人民郵電出版社的“圖靈系列”，我個人感覺其中的書的選題和印刷都還不錯，雖然也會有一些比較爛的作品出來了。

　　今天看了一篇很有意思的文章， http://www.aygfsteel.com/uiiang/archive/2006/10/30/77993.html ，介紹了種種項目中的編碼的惡習(xí)，其中很多的東西看起來真的是很搞笑，比如趴在Tab上睡著了那個，用中文做變量名的，還有 if(condition) a  else a 那個也比較搞笑，算是夸張了點。

　　不過想想看，自己一直都在算是比較正規(guī)的軟件企業(yè)，編碼規(guī)范還是有一定的要求的，不會出現(xiàn)這么搞笑的問題，不過有些問題還是會經(jīng)常的犯，比如說，又一次看一個同事寫一個方法寫了 1500 行，我立刻讓他改，最后精簡代碼，分開寫，也算是減少到可以接受的程度，另外一個惡習(xí)就是復(fù)制代碼，很多開發(fā)人員自身都是不怎么會寫代碼的，做開發(fā)就是找過去相識的，復(fù)制，粘貼，改，所以會出現(xiàn)一堆比較搞笑的問題，于是，錯誤便不是自己犯的了，人家寫錯了，自己也就抄錯了，我在第一次參加 Code Review 的時候就碰到這個情況，我自己的東西都是自己手工寫的，出現(xiàn)了一些問題，被大家指出來了，其它人寫的東西都是抄來抄去，發(fā)現(xiàn)問題都不是自己的，因為改過去的代碼需要上面授權(quán)，還有一堆測試要重做，所以看大致是可以用的也就蒙混過關(guān)了，造成了越來越混亂的代碼。

　　其實說來要把代碼寫的更好一點沒有想象中那么難的，凡事從小做起，從點滴做起，慢慢的把一些好的東西變成自己的習(xí)慣，重要的是要積累，而不是放任自流，多去看看人家著名的開源項目，看看人家代碼是怎么寫的，多去和自己的比較，然后善于用一些 Audit 工具評估自己的代碼，讓自己對自己的代碼中出現(xiàn)的問題有一個更明確的認識，然后慢慢的去改變自己的習(xí)慣，其實從長遠角度來說對自己有很大的好處的，起碼自己的編碼能力提升了，基礎(chǔ)更加穩(wěn)固了，有能力去勝任更高級的工作，不然，天天復(fù)制別人的代碼，自己又天天只能寫出來一些不符合規(guī)范的代碼，而自己又天天不去想不去問，一直這樣下去，開發(fā)能力還能提高嗎？

　　其實我還是很喜歡一本書《代碼大全 2nd》，今年上半年才出來的中文版，里面針對我們開發(fā)的時候出現(xiàn)的問題給出了很多規(guī)范和解決方案，我會經(jīng)常抽空去看看這本書，然后想想自己該如何去改善自己的開發(fā)習(xí)慣，去寫出更好的代碼，另外就是用一些 Audit 工具去針對自己的代碼做出一些評審，比如 CodePro，另外我們一些同事在 Maven 上用一些插件對 CVS 上的代碼做出 Audit 并發(fā)布在項目站點上，這些都是不錯的手段了。

　　其實說來最重要的還是自己的態(tài)度，工具，好的方法都不能轉(zhuǎn)變對于開發(fā)惡劣的態(tài)度的。

     摘要:   閱讀全文      摘要: 這幾天突發(fā)奇想，過去通過一些對 Navigation 的實現(xiàn)來省去了 JSF Navigation 的配置，現(xiàn)在又有新的想法了，能不能在 face-config.xml 中連 Managed Bean 都不要配置了呢，答案是肯定的，并且在實踐中也得到了證明。  閱讀全文     花了近一周的時間，把 iCustomer 大改了一番，其實說來也沒有特別大的變化了，修改的東西只不過是一些過去的一些bug和網(wǎng)上朋友們的一些建議，其實重點還是放在改 bug 上，另外就是 Order 這部分系統(tǒng)的領(lǐng)域模型重構(gòu)，Order 與 OrderItem 之間的關(guān)聯(lián)由原來的 one-to-many 改成了現(xiàn)在的 composite-element 方式，參考了 Hibernate Reference 的內(nèi)容，從理解上來說這樣的關(guān)聯(lián)方式也是比較合適的，有過去的松散的關(guān)聯(lián)方式換成了現(xiàn)在這樣緊密的關(guān)聯(lián)方式。通過前面近兩個月對 Hibernate 概念更深層次的思考與理解，現(xiàn)在在處理起這樣的問題都變得輕松了很多，沒有那么多的問題會很讓我在開發(fā)中卡殼，而且是那種一卡就卡上個好幾天不能解決的。當這樣的關(guān)聯(lián)關(guān)系復(fù)雜了以后，Hibernate 的功效才更好的發(fā)揮出來了，我們拿關(guān)聯(lián)對象就不用再寫一堆方法去拿了，需要的時候去取，Hibernate 就會自動的取幫你取好。實際上這次改 Order 部分時候，很多情況下都是在刪過去的代碼，過去的方式真的太復(fù)雜了，全部要自己手工一個個的去拿，簡直就是把 Hibenate 當 SQL 用，從思想上來說，這顯然是不正確的。

    另外想想看，如果在一個項目中用起 Hibernate 或者使用同樣方式的 EJB3 Persistence 真的會存在著太多的風(fēng)險了。Hibernate 走的是方式上的變革，我們必須去用新的思想去考慮問題，而不是僅僅用用它而已，我們需要從對象建模的角度就開始考慮 ORM 的存在，以對象為中心的方式去組織業(yè)務(wù)邏輯，而不是以表為中心去組織，剛開始用 Hibernate 的時候，大部分情況還是在考慮表如何如何的，但是用了一段時間以后，發(fā)現(xiàn)這樣的方式和 Hibernate 真正的核心思想相差太大了。所以說要正確的去用 Hibernate 決不是看了一兩本書，做了幾個簡單的 CRUD 就可以的了，需要在許多復(fù)雜關(guān)聯(lián)中經(jīng)受考驗才可以，而一個要很好的去用 Hibernate 的項目，一定是要有這樣經(jīng)驗的人去做才可以的，幾個剛翻幾頁書，知道怎么用就去拿 Hibernate 做項目的人真的還是遠遠不夠的，這種情況在 iCustomer 0.1 版本中表現(xiàn)的非常突出，混亂的配置和關(guān)聯(lián)關(guān)系，讓使用了 Hibernate 后，代碼未減反增，我努力在 0.2 的版本中做出一些修改了，當然只是比原來好了一些，離真正理想的情況還是有差距的。當然有空我會把這樣的一些經(jīng)驗和大家分享一下，讓大家在學(xué)習(xí) Hibernate 上少走一些我曾經(jīng)走過的彎路了。

    又用回了 JSF，開始發(fā)現(xiàn)這樣的方式真的有很多的好處了，而且在 JSF 的使用和經(jīng)驗上有一些積累，用它來建立一個不大的項目經(jīng)驗應(yīng)該是足夠的了。Backing Bean 的方式比 Action 的方式配置文件的數(shù)量上要減少了很多，說能夠減少到原來的 1/4 甚至更多都不為過了，因為我們一般情況下一個 Backing Bean 對應(yīng)一個頁面，只需要配置一處，而一個頁面中如果有很多操作的話 Action 方式就需要配置很多了，比如一個查詢頁面，查詢需要一個 Action，查看查詢的一個記錄需要一個 Action，刪除記錄需要一個 Action，修改一條記錄又需要一個 Action，算起來正好 1:4，是不是省了很多配置呢，在結(jié)合擴展的 Navigation 方式，連 Navigation 都不需要配置了。配置文件真的少了很多了。

    用到了一個 Tomahawk 組件中獨有的 forceId 屬性，不能說有多爽，但是可以讓你在寫 JavaScript 的時候省了好一些代碼了，過去一個組件的 id 生成出來就是 form:cid 的形式，而用了 forcdId = "true" 后，生成出來的 id 就是你在組件的 Tag 中實際定義的值，當然用的時候也要小心了，千萬不能重復(fù)，包括同一頁面中不能重復(fù)，也包括一個頁面中包含另外一個頁面時不能重復(fù) 。

    連續(xù)三天做了三場 Share Session，講了一些關(guān)于系統(tǒng)開發(fā)的三個層的東西，Web Layer / Business Layer / Persistence Layer 分別以各個層面最優(yōu)秀的技術(shù)為例和組內(nèi)組外的同事們分享了一些我關(guān)于這些技術(shù)的理解。

    雖然說講的還不是很好了，但是這三天卻給了我很大的提高，不僅僅是技術(shù)上面，更多的是在一種表達能力方面的。可以說是第一次真正意義上的上臺講東西了，因為面對的不光是同組熟悉的同事，還有很多不是太熟悉的，還有幾位老大，甚至在最后一次講JSF的時候，大老板還進來坐了一會，壓力還是挺大的，雖然要講的東西已經(jīng)在之前在腦子里演練無數(shù)次了，但是要想把自己想的東西和別人講清楚，的確不是那么容易的事情了，當發(fā)現(xiàn)下面的同事滿臉的迷茫，就得趕緊換一個角度來說明問題，不過還算過得去的是，自己并沒有太多的緊張了，雖然是第一次正式的在臺上講東西，面對面的對著大家，不過自己要講的東西心里還比較有底，心里比較踏實了，于是也就沒有太多的緊張了。

    通過三天對各個方面的技術(shù)的介紹和總結(jié)，其實也不知道大家真正能理解多少，因為太多東西沒有經(jīng)過實踐是不會有太深刻的理解的，雖然有些東西當時是聽懂了，但是卻不會深深的刻進你的腦子，時間一長就忘記了。三天里，總結(jié)了這一年來我對 Java Web 開發(fā)的幾個方面的理解了，雖然這一年學(xué)到了很多很多，但還有太多太多的不了解了，有些東西當自己看的時候覺得自己了解，但是當需要把這個東西和別人分享的時候，卻發(fā)現(xiàn)自己有太多太多的不知道了。

    似乎很久沒有寫些什么了，因為最近想的太多，做的太少了。
    第一次發(fā)現(xiàn) Hibernate 原來并不是自己過去想像的那樣簡單，它很復(fù)雜，很強大，卻能讓你最后要做的事情變的很少，雖然它帶來了如此多的好處，但如果想真正的用好它，必須有一個非常熟悉它的人在你的團隊里，這樣才能夠最大的發(fā)揮它的巨大威力。雖然每個人都可以花不多的時間去用會 Hibernate ，但卻只有很少的人能夠靈活的駕馭它，讓它為你服務(wù)，因為它同傳統(tǒng)的關(guān)系數(shù)據(jù)庫可以說是截然不同的兩條路，從玩 SQL 走過來的人，多多少少會受到它的限制，而變得不易接受ORM，像我就是一個典型了，當?shù)玫礁呤种更c的時候，發(fā)現(xiàn)過去的很多想法偏離軌道還是挺遠的了，幸虧有人指點，得以走回正道。
    作為 J2EE 中另一個驕傲，Spring 也以它的獨特觀點改變了 J2EE 的世界，過去用 Spring 只是稍微理解了它的 IoC 的思想，和簡單的使用了它的 Transaction 管理功能，最近細看了一下它的 AOP 感覺震動還是挺大的。基于 Interceptor 的 AOP 真的是很好用，也很強大，甚至于說，它會是一種改變 Java 開發(fā)模式的一種動力了，雖然只是剛開始看看，沒有什么深刻的理解，但卻也能夠有一些很大的感觸了，或許 AOP 在目前還是剛剛起步，或許太多的人沒有接受它理解它，AOP 的應(yīng)用層面還是比較低了。

用 Hibernate 碰到一個很傻的問題，在 iCustomer 中有這樣的關(guān)聯(lián)，有服務(wù)記錄，該記錄會與 Customer 關(guān)聯(lián)，當時為了在不需要的時候不在 VO 里 new 出 Customer，用了這樣的寫法。

public Customer getCustomer() {
?if (null == customer) {
??customer = new Customer();
?}
?return customer;
}

這樣看似沒有問題，當使用到 Customer 的時候才會創(chuàng)建該對象。但是每次卻會報告臟數(shù)據(jù)錯誤，其實最重要的是我忽略了一個問題，這個方法同樣會被 Hibernate 調(diào)用，在 null 的時候給 new 出一個相應(yīng)的 Customer，這樣就會出現(xiàn)問題了，如果你把 Customer 設(shè)成 null，Hibernate 調(diào)用該方法時就會自動給你 new 一個 Customer，并沒有任何 id，這樣在保存的時候會引發(fā)臟數(shù)據(jù)錯誤。所以一定要避免這樣的寫法。

別人給出的建議是把這樣的 new Customer 的邏輯放在外面寫，手動處理 Customer 的創(chuàng)建。頁面上傳遞的是 Customer 的 id，后臺手動加載 Customer 的 PO，然后 set 給 Support。

　　經(jīng)過大約四個月的開發(fā)，和五位開發(fā)設(shè)計及美工人員的努力，AgileJava iCustomer 的第一個不是那么穩(wěn)定的版本終于拿出來了，我們終于走出了我們的第一步，在這期間，我們也得到了很多朋友的支持和幫助，我們要感謝這些支持者的貢獻。

　　在這個階段里，我們團隊成員一起把我們研究 JSF, Spring, Hibernate，以及 Acegi 的成果都集中在這個項目中了。雖然很多東西都只是那么點點滴滴，但是在這期間有很多朋友在積極的幫助我們，參與我們的 OpenDoc 活動，把自己的寶貴時間分享出來，為大家?guī)砹撕芏嗪芎玫奈臋n，上周末，我們得到了 javascud 的大力支持，我們有了自己的 SVN，有了自己的 JIRA，這樣的話，我們便可以建立我們自己的協(xié)作開發(fā)平臺，讓我們的經(jīng)驗和更多的朋友分享，同時，我們也歡迎更多的朋友能夠參與到我們的開源活動中來，因為有了你們，我們才可以更壯大，因為有了你們，我們才可以更成熟，因為有了大家的齊心協(xié)力，我們才能為了一個共同的目標去奮斗，因為有了大家的協(xié)作，我們才會在共同努力中進步。

　　開源也不是一句口號，我們只想用我們自己的行動來證明這一切，正因為我們是熱愛開源的，所以我們才會去努力做的更好；正因為我們有著一個奮斗目標，我們才會孜孜不倦的去奮斗。此前 SpringSide 為我們做出了一個榜樣，EasyJF 讓我們夢想在自己的努力中實現(xiàn)，CowNew 也成為我們開源一個很好的先例，正是因為大家有這個夢想，有這些前輩們的努力，我們才看到國內(nèi)開源的希望。

　　其實我們更希望做到的，只是讓新的技術(shù)能夠更貼近實踐了，讓大家的實踐能夠更容易，讓大家的開發(fā)能夠更輕松，所以我們才從過去只是為了朋友做的一個小小的系統(tǒng)中找到方向，所以我們的開源團隊名稱叫做 AgileJava 就是為了讓我們的開發(fā)更敏捷。

　　下面我簡單的介紹一下我們現(xiàn)在已有的系統(tǒng)和我們未來的目標：

　　AgileJava iCustomer 系統(tǒng)是一套開源的 CRM (客戶關(guān)系管理) 系統(tǒng)，使用了新一代輕量級 J2EE 技術(shù)： JSF，Spring，Hibernate， Acegi 等作為系統(tǒng)的基礎(chǔ)開發(fā)框架，力圖打造一個輕快好用的 J2EE 應(yīng)用。

　　在系統(tǒng)開發(fā)過程中，我們同時將系統(tǒng)中的基礎(chǔ)框架以及大量可以簡化 J2EE 應(yīng)用開發(fā)的組件從應(yīng)用中抽取出來，并獨立提供給廣大開發(fā)人員，作為項目開發(fā)的基礎(chǔ)框架，為大家進行快速開發(fā)提供支持。我們?yōu)樵摽蚣苊麨?AgileJava Framework。 AgileJava Framework 的目標是致力于為廣大開發(fā)者提供一個敏捷高效的 J2EE 快速平臺。

　　另一方面，我們將以此框架為基礎(chǔ)，通過 Eclipse Plugin 的方式提供一套完整的基于代碼生成的解決方案，用于快速生成應(yīng)用的基礎(chǔ)代碼。該開發(fā)工具同樣沿用我們 AgileJava 的名稱，叫做 AgileJava Studio。 AgileJava Studio 將致力于減少開發(fā)工作中的重復(fù)勞動，給開發(fā)者帶開更好的開發(fā)體驗。

　　我們將會將 AgileJava iCustomer， AgileJava Framework， AgileJava Studio 作為開源項目來運作，一方面建立一個完整的企業(yè)級的客戶關(guān)系管理系統(tǒng)，另一方面建立一個為 J2EE 項目提供快速開發(fā)能力的基礎(chǔ)框架和開發(fā)工具。

　　因為國內(nèi)的開源模式一直沒有什么好的先例，并且開源的路線在國內(nèi)因為一些誤解方面的問題，一直沒有很好的發(fā)展起來，雖然我們選擇了開源，但是我們更多的希望只是通過一個完整的企業(yè)級應(yīng)用的方式來探索開源的方向，并為我們中小型企業(yè)級應(yīng)用打造一個方便易用功能強大的解決方案，用我們的實踐帶給所有參與者一些經(jīng)驗，無論是開源方面的經(jīng)驗，還是在輕量級 J2EE 應(yīng)用開發(fā)的經(jīng)驗。雖然國內(nèi)很多軟件企業(yè)都在用這些技術(shù)，但因為版權(quán)的問題，無法和更多的朋友分享，所以我們更需要一個開放的交流環(huán)境，通過這樣開源的方式，通過大家的努力，把我們在實踐中的經(jīng)驗?zāi)贸鰜恚痛蠹曳窒恚餐龠M我們軟件開發(fā)的大環(huán)境的改善，共同提高大家的開發(fā)能力和開發(fā)水平。

　　在這里，我們鼓勵的是一種知識共享，通過這樣的共享，我們把我們自己擁有的一份知識擴展到大家擁有的無數(shù)份知識。我們通過自己的實踐，我們能夠更深入的去了解了現(xiàn)有的各種技術(shù)的長與短，通過大家的交流與協(xié)作，我們在知識上互相彌補。通過這樣的實踐，我們不光是再做我們這個系統(tǒng)，更多的是我們有了更多的思想，更多的經(jīng)驗，我們有能力去打造更好的系統(tǒng)。

　　我們目前采用了以 JSF, Spring, Hibernate 為中心的主體框架，并努力使之擴展到一個中小型商業(yè)應(yīng)用所需要的主要技術(shù)領(lǐng)域，并使之更簡單易用。

				 目前采用的技術(shù)：
 JSF (Myfaces Implement)，完整的視圖層解決方案，一個標準的事件驅(qū)動的 MVC Framework。
 Spring Framework ： 其 IoC 容器為我們的業(yè)務(wù)對象控制帶來了很大的便利。
 Hibernate 3 ： 目前最優(yōu)秀，使用面最廣的 ORM Framework。
 Acegi ： 一個基于 Spring 的通用 Security Framework。
 Quartz ： Java 世界最好也幾乎是唯一的 Job Schedule 工具，為我們調(diào)度 Batch Job 提供了很大的便利。
 Shale ： struts 社區(qū)在 JSF 領(lǐng)域的重大貢獻，以 JSF 為基礎(chǔ)為我們提供了一系列好用的東西。

		

				 預(yù)計后面準備采用的技術(shù)：
 Compass + Lucene ： Java 世界里最好用的開源 Search Engine 組合，Compass 使 POJO 能夠更方便的去使用 Lucene 的底層引擎。
 BIRT ： Eclipse 社區(qū)貢獻的一個重量級 BI 應(yīng)用。當?shù)谝谎劭吹剿鼤r，就拋棄過去的 iReport + JasperReport 的組合了,夠?qū)I(yè)。
 Facelets ： 為 JSF 量身定做的模板框架，JSF 的 Fans 們不用再靠著 struts 的 tiles 也能活啦。
 AjaxAnywhere ： 不用寫 JavaScript 也能 Ajax ，它為我們提供了這樣的可能。
 ICE Faces Component?: 當它的第一個beta版本出來的時候，我就對它頗有興趣，或許是目前免費的 JSF 組件庫中最好的 Ajax 實現(xiàn)了。

		

　　我希望能夠有更多熱愛開源的朋友加入到我們的行列中來，不論你來自何方，做著什么樣的工作，只要我們有著開源的這個共同的目標，我們就可以共同的去為著自己的愛好，自己的理想，自己的信念所奮斗，記住，開源決不是三分鐘的熱度，需要你持之以恒的奮斗。

     摘要: 過去的一段時間，一直有人拿 JSF 的 Navigation 當靶子，批評 JSF，其實細心的人會發(fā)現(xiàn)，在 Java 世界，這樣的批評常常是很片面的，幾乎所有成熟的應(yīng)用框架，在除了實現(xiàn)某些默認的功能外，還保留一些擴展的接口，提供了相當?shù)臄U展性，比如說 struts， spring 等很多的 web framework 都提供了很多擴展的接口，當然，JSF 也一樣。JSF 的 Navigation 中，我們一個 page 都有一個 from-view-id ，它的每個 navigation 出口 to-view-id 都必須定義，所以在不同的 from-view-id 中會有一些重復(fù)的 to-view-id，并且每當有一個新的 navigation 路徑，我們都必須配置這個路徑，才能夠在 action 中正確的轉(zhuǎn)向我們這個路徑。很多情況下，這樣的方式用起來都不是很爽，我們需要有一些簡單的方式，我們在 action 事件中，直接 return 一個 page 的 path 就會直接 forward 到這個 page ，在用的時候會方便一些，有沒有辦法去做到呢？  閱讀全文