開發規範學習心得
單超
2007.8.15日
1。文件名大小寫的規定，JSP文件必須全部小寫。
原因：開發時用的是windows的平臺，windows並不區分文件名的大小寫。而真正實施的時候使用的是UNIX平臺，他完全區分大小寫，所以如果開發時候不遵守這個規範，很可能就會在windows平臺下把這個問題遺漏掉。
2。在update操作前，必須先把這條記錄查出來再update
原因：這個涉及到Hibernate的緩存機制，不是很理解。
3。catch塊中不允許寫任何邏輯代碼。
原因：正常的業務邏輯不應該依賴於異常的捕獲。
4。原則上不允許啓跨方法的長事務。
原因：長事務比較複雜。
長事務涉及的問題有這麼幾個：
第一、長事務的開啓和關閉應該由哪個方法來做。
第二、長事務必須在一個線程上完成，否則沒有意義。
解決方法：
第一、判斷線程上是否有開啓的事務，如果有，說明當前方法是事務內的一個子部分，不需要開啓和關閉事務，如果沒有，說明該方法是事務的發啓者，必須開啓和關閉事務。
第二、把事務綁定在當前線程之上，就解決了一個事務必須在一個線程上完成的問題。
5。事務必須儘量短小
說明：組織數據的操作應該放在事務的外面，事務應該只執行OP操作，保持儘量簡短
原因：如果事務體寫的比較大，就會出現以下三個問題
第一、佔用回滾段資源
第二、事務執行期間鎖表
第三、佔用連接池的連接
6。事務的提交和回滾必須非常小心
原因：如果在事務內部使用了循環，判斷，分支等結構，必須讓每一個分支都走到提交或回滾的操作上。否則很容易產生既沒提交也沒回滾的髒連接。這樣就會鎖定很多的表。會造成十分嚴重的錯誤。
7。調用存儲過程(這一塊沒太明白)
注意：調用存儲過程這一塊，不是使用hibernate寫的，而是使用了JDBC。因爲hibernate作爲一個通用的ORM，不應該也不會去過多地關注各個數據庫的特殊處理，而調用存儲過程的操作各個數據庫都是不一樣的，所以hibernate對這方面的支持就十分微弱。
注意：存儲過程中發生的錯誤是無法用java代碼捕獲的，所以所有調用存儲過程的JAVA代碼都會得到標識了存儲過程執行成功或失敗的返回值，我們必須根據這個值，手動地拋出一個異常。
8。防止重複提交
重複提交有以下三種情況：
第一、連續點按紐
第二、刷新頁面
第三、後退(客戶不會經常犯這樣的錯誤)
解決辦法有三個，分別針對以上三點
第一、javaScript控制，又細分爲兩種，一種是按鈕置灰，一種是在頁面加載時，在page_init()方法中，將表單裏的值全部記錄下來，然後在點業務按紐時，判斷當前表單值是否與加載時的值一樣。如果一樣，不允許提交。
第二、所有業務邏輯的Action配置的ActionForward都必須重定向到查詢頁面，注意：一個是必須用重定向，而不是轉發，再一個是必須重定向到別的，無法提交業務邏輯數據的頁面。
第三、使用struts的令牌機制。(具體的不太明白)
9。保留查詢條件(form=save)
原理：以當前的url爲key，以查詢form中的值集爲value，在session中保存
10。保留分頁信息(有個專門的標籤，忘了是什麼)
原理：以當前的url爲key，以翻頁按紐上的href爲value，在session中保存
11。引入腳本文件或CSS文件時，必須使用base標籤的屬性而不能自己引入。
原因：如果自己引入，就必須寫出CSS或JS的地址，那麼就存在兩種選擇，一是寫地址的絕對路徑，二是寫相對路徑。這兩種做法都存在以下問題。
第一：如果寫絕對路徑，就相當於把項目名硬編碼進去。
第二：如果寫的是相對路徑，當頁面發生遷移時，由於頁面的URL顯示的是Action的地址。那麼就會出現相對路徑的參照點不確定，那麼相對路徑也就沒有意義了。
12。如果要在頁面加載完畢後執行一段javaScript代碼，必須將這段代碼寫在page_init()方法中，而不能在頁面的底部寫這些代碼段。
原理：page_init()方法是在base的onload屬性中設置了的，當頁面完成加載時，就會自動調用page_init()方法。page_init()方法在JS文件中被定義成一個空的方法，需要我們重寫這一方法。
13。按鈕的functionId必須要寫
原因：爲了以後賦權的方便
原理：session中緩存了這該用戶的權限，在頁面加載時，自定義的button標籤，會根據這個標籤上的functionId屬性，和session中的用戶權限，自動判斷這個用戶有沒有權限看到這個按紐。如果用戶沒權限，就根本不往頁面上生成這個按紐的代碼；如果有權限，才往頁面上寫這行代碼。
14。所有的BS必須實現一個統一的接口。（不記得叫什麼接口了）
原因：由於所有的BS都是一個類型的東西，所以理論上來說，他們屬於面向對象世界中的一類對象，就應該有一個接口來統一他們。但是由於現在這個接口還是一個空的接口，所以還沒什麼用處。但是如果以後需要給所有的BS都加上一層功能，那麼只需要在這個接口中改就可以了，現在這樣做，只是爲以後留出一個好的基礎。
原理：JAVA中的接口分爲兩種類型，一種叫做功能接口，也就是定義了方法簽名的接口。第二類是叫標誌性接口，這種接口不定義任何方法，只是用來標識某個對象是屬於哪一類的，比較典型的是JAVA的序列化接口。
15。在檢查textarea和長輸入框的內容長度時，必須使用getBytes方法獲取長度，不能使用length屬性獲取長度。
原因：javaScript只檢查字數，也就是把漢字也當成一個長度，但是漢字其實是兩個比特的。
原理：這個getBytes()方法是通過css 的behavior綁定上去的。css behavior確實是個很牛B的東西。但是目前沒興趣搞明白。
16。UTF-8字符集是unicode的一個子集，是用12位表示一個漢字，也就是用1.5個B表示一個漢字的。
17。tab頁的權限跟button一樣。
18。使用session時必須小心。
原因：真正的原因不是因爲session耗費資源，這些都可以通過session管理策略來實現性能的優化。真正的原因是在weblogic做系統集成的時候，會發生一個叫session漂移的情況。
session漂移:一臺服務器把它內存中維護的某個session先序列化，然後傳送給另一臺服務器，接受到session的服務器，將這個session重建。經常發生的問題，
一、如果session中的對象沒有實現序列化接口，那麼就無法序列化，也就無法正確還原。
二、如果session中存放了大的集合，或大的javaBean。也就是說，存放了大的數據塊，那麼session漂移時，發生問題的可能性十分大。
目前爲止，部門解決這個問題的方法，是要求客戶使用硬件代理。硬件代理支持一種以客戶爲單位的負載均衡算法。也就是一個客戶的請求始終發送給同一個服務器。
補充：代理轉發請求的策略有這麼幾個。
第一類：weblogic自帶集羣軟件的算法
1。容災算法。一直只用一臺服務器，直到這臺服務期器掛掉，就用別的備用服務器。
2。輪詢算法。將請求輪流發給各個服務器
3。負載均衡算法。測試服務器負擔，把當前請求發給負載最輕的服務器。
第二類：硬件代理的一個比較好的算法
以用戶爲單位轉發，一個用戶的請求總是發給同一個服務器。這樣就不會發生session漂移的問題了。