vulcan

去年的一個問題，后來項目時間緊就擱下了，采用了替代方案，但是總覺得不那么完美，今年升級開發，想解決了，然后才有了這個想法。之前也知道SpringSide，但是沒有想過取看，今天因為一個問題搜google，居然發現我之前對于java web開發的一些想法居然和SpringSide一樣！又多了解了一下，發現這個項目的貢獻者都是國內jee開發領域的高手，所以呢，肯定比我的那些實現完美得多。暫時放下自己的代碼，好好看看SpringSide源代碼，因為想法有些一致，那么看起來肯定會很愉快的，如果全部和我的胃口，那么就轉到SpringSide了，如果不完全合我胃口，那么就把我關心的一些代碼搞明白后，選擇性吸收進項目了。
下面是讀代碼的一些感受：
(1) DAO的實現挺對我胃口的，比較喜歡。我的范型DAO是從Hibernate網站上取下來改進的。主要增加了一個可以接收List<Criterion>的重載方法還有分頁的功能。List類型的Criterion，方便了在上層靈活的利用添加條件，而不用每次都去轉成數組，傳給原本只接受可變參數的方法；分頁和Order的支持操作比我的實現優雅得多。不過卻希望可以給范型DAO的主鍵也增加一個范型參數，因為對于復合主鍵的參數傳入，如果有一個類型安全檢查可能要好一些。
(2) 先有雞還是先有蛋的問題，這個問題可能是我理解得不清楚還是Struts2的機制變了。看到SpringSide2中core.web包中有一個Struts的支持類，支持了基本的CRUD操作，這個問題，我卻之前沒有想過，導致有好多很簡單的，但是又不得不寫代碼和配置的webwork Action。于是我就想著給webwork也寫了這樣一個支持類。正好springside3中有對Struts2的一個支持類，參考了一下，struts2和webwork的關系想必大家都知道。應該有可以借鑒的東西。不過借鑒過來之后，發現行不通有問題，后來居然是一個先有蛋還是先有雞的問題：因為攔截器的配置順序。在springside3的struts2支持類中，實體的根據id從數據庫載入或者新建放在了prepare方法中，而這個prepare是使用了一個要求子類重載的getId方法，毫無疑問，在我們通常的使用中，getId肯定是從表單參數中獲取的，所以也就意味著webwork的param攔截器必須在prepare攔截器之前，由于使用了prepare來準備entity,那么model-driven攔截器必須在prepare攔截器之后，不過webwork model driven要能正常工作，實際上，model-driven又必須是在param攔截器之前，在使用ognl進行參數注入之前，必須先通過model-driven攔截器把實體準備好！這就形成了一個先有蛋還是先有雞的問題了。不知道是不是我理解webwork還不夠深入，這個問題如果是采用prepare來做這個工作，那么這個問題是無解的。最終，我還是按照自己的理解做了一個，提供一個getId()默認實現，并且在getId()方法中，不依賴于param攔截器，而是直接從ActionContext中獲取提交的表單Id參數，如下的代碼：

并且還需要提供一個setIdParamName()方法，這樣就可以在webwork配置中注入idParamName了。
當然還可以這樣做:
把springside3中struts支持類中prepare做的工作分散到幾個crud操作方法中。首先在：input方法中，根據id是否有值，新建或者從數據庫中load一個entity，這是在插入或者更新一個entity之前的操作；而getModel方法中直接放了一個創建一個entity instance的方法，因為model-driven主要是拿來做表單參數接收的，所以是否從數據庫中load一個entity其實是無所謂的，反正會被表單參數全部覆蓋。不過要是可以在getModel()方法之前知道是對哪個entity進行的操作，然后load該對象，就可以在表單中只傳遞部分屬性值了。按照model-driven必須在param攔截器之前的原則，除非把要編輯的entityId放在session而不是頁面參數中，然后在getModel方法中預先判斷是否是該Action的編輯操作，而load該entity。