花了近一周的時間，把 iCustomer 大改了一番，其實說來也沒有特別大的變化了，修改的東西只不過是一些過去的一些bug和網上朋友們的一些建議，其實重點還是放在改 bug 上，另外就是 Order 這部分系統的領域模型重構，Order 與 OrderItem 之間的關聯由原來的 one-to-many 改成了現在的 composite-element 方式，參考了 Hibernate Reference 的內容，從理解上來說這樣的關聯方式也是比較合適的，有過去的松散的關聯方式換成了現在這樣緊密的關聯方式。通過前面近兩個月對 Hibernate 概念更深層次的思考與理解，現在在處理起這樣的問題都變得輕松了很多，沒有那么多的問題會很讓我在開發中卡殼，而且是那種一卡就卡上個好幾天不能解決的。當這樣的關聯關系復雜了以后，Hibernate 的功效才更好的發揮出來了，我們拿關聯對象就不用再寫一堆方法去拿了，需要的時候去取，Hibernate 就會自動的取幫你取好。實際上這次改 Order 部分時候，很多情況下都是在刪過去的代碼，過去的方式真的太復雜了，全部要自己手工一個個的去拿，簡直就是把 Hibenate 當 SQL 用，從思想上來說，這顯然是不正確的。
另外想想看，如果在一個項目中用起 Hibernate 或者使用同樣方式的 EJB3 Persistence 真的會存在著太多的風險了。Hibernate 走的是方式上的變革，我們必須去用新的思想去考慮問題，而不是僅僅用用它而已，我們需要從對象建模的角度就開始考慮 ORM 的存在，以對象為中心的方式去組織業務邏輯，而不是以表為中心去組織，剛開始用 Hibernate 的時候，大部分情況還是在考慮表如何如何的，但是用了一段時間以后，發現這樣的方式和 Hibernate 真正的核心思想相差太大了。所以說要正確的去用 Hibernate 決不是看了一兩本書，做了幾個簡單的 CRUD 就可以的了，需要在許多復雜關聯中經受考驗才可以，而一個要很好的去用 Hibernate 的項目，一定是要有這樣經驗的人去做才可以的，幾個剛翻幾頁書，知道怎么用就去拿 Hibernate 做項目的人真的還是遠遠不夠的，這種情況在 iCustomer 0.1 版本中表現的非常突出，混亂的配置和關聯關系，讓使用了 Hibernate 后，代碼未減反增，我努力在 0.2 的版本中做出一些修改了，當然只是比原來好了一些，離真正理想的情況還是有差距的。當然有空我會把這樣的一些經驗和大家分享一下，讓大家在學習 Hibernate 上少走一些我曾經走過的彎路了。
又用回了 JSF，開始發現這樣的方式真的有很多的好處了，而且在 JSF 的使用和經驗上有一些積累，用它來建立一個不大的項目經驗應該是足夠的了。Backing Bean 的方式比 Action 的方式配置文件的數量上要減少了很多，說能夠減少到原來的 1/4 甚至更多都不為過了，因為我們一般情況下一個 Backing Bean 對應一個頁面，只需要配置一處，而一個頁面中如果有很多操作的話 Action 方式就需要配置很多了，比如一個查詢頁面，查詢需要一個 Action，查看查詢的一個記錄需要一個 Action，刪除記錄需要一個 Action，修改一條記錄又需要一個 Action，算起來正好 1:4，是不是省了很多配置呢，在結合擴展的 Navigation 方式，連 Navigation 都不需要配置了。配置文件真的少了很多了。
用到了一個 Tomahawk 組件中獨有的 forceId 屬性，不能說有多爽，但是可以讓你在寫 JavaScript 的時候省了好一些代碼了，過去一個組件的 id 生成出來就是 form:cid 的形式，而用了 forcdId = "true" 后，生成出來的 id 就是你在組件的 Tag 中實際定義的值，當然用的時候也要小心了，千萬不能重復，包括同一頁面中不能重復，也包括一個頁面中包含另外一個頁面時不能重復 。
posted on 2006-08-21 11:15
steady 閱讀(1789)
評論(1) 編輯 收藏 所屬分類:
AgileJava