ava web 開發過程中常見的一些錯誤
阿新 • • 發佈:2019-01-09
現在通常人們討論和實現Java WEB應用時,往往過度關注框架和平臺,對常見實現的各種模式未有深入的考慮。自從在IBM DevelopWork上見到一個名詞"錯誤模式",就一直仔細研究和收集各種錯誤模式,現在就針對各WEB應用中最常見的增刪改查,談一下常碰到的錯誤模式。
增加、編輯時常見錯誤
1、沒有進行,介面上的效驗問題
有人認為,這個不算錯誤,呵呵,那我也不說什麼了。很多情況下,初學的人會完全忽略這一塊,剛開始我就是的,還感覺這個就像程式把門的第一關口啊,最好能提前預防。
一般情況下,都是用javascript直接實現的,也有基於框架的後臺驗證,如DotNet和WebWork的驗證器等。通用的方法,是充分發揮正則驗證的潛力來解決好這一塊。
2、後臺效驗問題 JS+RPC OR Server
前臺的效驗完畢後,往往還需要進行後臺的邏輯效驗,如檢查是否重名等。一般是通過一組查詢來實現的。因為只是只讀的查詢,個人認為,怎麼實現都沒關係。通常是在後臺,提交資料庫前驗證。其實業可以通過ajax技術,在前臺驗證,隨著技術的發展,我想還是通過AJAX統一到前臺實現比較一致。
3、更新失敗返回問題
更新失敗的因素是多方面的,如資料連線斷開等。往往,很多人都沒有進行相關的保護,沒有相應的提示,或者提示返回後,客戶的輸入就丟失了。這些都是應該仔細考慮並解決的問題,很可惜,再大量學習各類框架和平臺後,相信很多人都沒有仔細的在這一塊加上那怕一點點保護。
4、編輯載入失敗返回問題
這個是個比較初級的問題,不過確實出現過,還是寫寫,看看自己忘了不.....
5、編輯載入,值還原問題,如回車丟失,空格丟失等
有時候,Html標籤寫的不好的時候,可能會丟值,如 回車,空格 ,<等符號
6、更新時,多步操作的事務保護機制不健全
這一點,本不該寫在此處,不過,我一直覺得這是個很重要的問題,所以還是加上。也許有人會說,我用Hibernate,這個問題就不存在了.....還是要重視啊,我見過有初學者,沒有很好的利用Hibernate的宣告事務標籤,或者根本不宣告...... 而且多步操作不寫在一個方法裡面,也不用手工的事務控制...寒,其實有些專案我自己都沒做到,因為各方面的原因@%^@#^@#^@^,悲哀ing.....
刪除常見錯誤
1、找不到記錄時錯誤
這個是個比較初級的問題,不過確實出現過,還是寫寫,看看自己忘了不.....
2、關聯資料不能自動檢查並返回資訊
對於一些有關聯的資料,應該通過檢查機制保護破壞性的刪除操作。
3、自動刪除關聯資料
這個對於一些POJO設計得非常好的系統,完全不用考慮的,呵呵不過,大家還是要很清晰的瞭解這種刪除的必要性,感覺初學者都忽略這些問題。
4、刪除時沒有清晰提示
通過JS保護只有一行程式碼,就可以給客戶一個避免錯誤操作的機會,何樂而不為呢,用框架的同仁們,你們這麼做了嗎?實際的系統,使用者不會忘了提這一點的。
檢視時錯誤
1、找不到資料時錯誤
這個是個比較初級的問題,不過確實出現過,還是寫寫,看看自己忘了不.....
2、一些值得顯示問題 如 回車、空格
加幾行轉碼的函式就可以避免,很多人忽略了,寒,如回車轉為<BR>,空格轉為
3、下拉表單資料的回顯問題 值-名對,顯示值,而不顯示名
下拉表單輸入時,大家都有解決方案了,回顯,就是一個查詢,請加上吧,不要讓自己眼睛不舒服。
分頁瀏覽時錯誤
1、找不到資料時的正確返回
這個是個比較初級的問題,不過確實出現過,還是寫寫,看看自己忘了不.....
2、翻頁後 條件保持問題(特別時有特殊字元時,如回車,"\"","\'"等)
要把條件傳遞到下一個頁面阿....
3、翻頁的效率問題
很多人沒仔細考慮,比如我自己,剛用Hibernate時,直接用一個完全查詢的HQL,取List.Count解決取總記錄的方法,結果,發現,這個查詢被執行了!!!現在改成一個專門取總行數的Count查詢...當然用專門對資料庫優化過的SQL和儲存過程,永遠是效率最高的方法
查詢時錯誤
1、查詢條件初始化問題
查詢條件如日期等,為什麼不給客戶一個最常用的時間段呢,可以避免使用者的操作
其實還有很多需要注意的細節容易出問題。如格式驗證...只讀欄位的控制.等等
一個完整的增刪改查應該有幾個部分的程式碼
1.新增載入
控制新增資料的預設初始化值
在Struct或者WebWork中,就是一個Action +一個檢視
2.新增提交
將使用者提交的新增資料,加入資料庫
在Struct或者WebWork中,就是一個Action
3.編輯載入
從庫中載入已有的某條資料方便編輯
在Struct或者WebWork中,就是一個Action +一個檢視
4.編輯提交
將使用者提交的修改資料,更新到庫中
在Struct或者WebWork中,就是一個Action
5.檢視記錄
從庫中載入已有的某條資料檢視
在Struct或者WebWork中,就是一個Action +一個檢視
6.刪除提交
將使用者指定的記錄刪除
在Struct或者WebWork中,就是一個Action
7.載入查詢
初始化查詢介面
在Struct或者WebWork中,就是一個Action+一個View
8.查詢提交
接受查詢介面的提交,並組合為查詢結果傳送給一個View
在Struct或者WebWork中,就是一個Action+一個View
也可以將請求轉交給分頁瀏覽頁面
9.分頁瀏覽
根據查詢條件和頁號,顯示特定資料頁的資料
在Struct或者WebWork中,就是一個Action+一個View
這裡,我沒有專門寫出formBean,個人認為FormBean只是一個工具
當然根據情況各種Action 和View可以進行各種整合,不過個人覺得,不管如何組合,這幾個環節都是很必要的,必須思路非常清晰才好。
附上我以前總結的一些常見的錯誤檢查表,給同事看的...
******************************************************************************************************
JAVA WEB應用常見的錯誤
在本系統中一些常見Bug和對策
1.Null指標錯誤
A.引用的Bean未在 Hibernate配置檔案,Spring配置檔案中正確的配置
B.呼叫的Session及Request 未能正確的取到
C.物件未初始化,或者在傳遞中失去了,往往使webWork託管的物件出現這種問題
D.未正確的寫上Getter,Setter方法
2.無任何提示的錯誤...
A.一般情況是HibernatePO執行的時候發生的錯誤,未將錯誤正確的丟擲..
B.轉入Error頁面採用Redirect模式,錯誤資訊不能顯示
其他
A.WebWork Action中未找到對應的對映
B.在彈出視窗中,Session丟失
C.Tomcat,MYSQL亂碼問題
在WebWork值得注意的是URL傳遞的引數,需要手工用toCN轉碼
Form傳遞的不需要
D.WebWork標籤的引用問題,Map request並不是和request對映的那個物件
有一個同名物件,但是型別是httpRequest的Request才是..
E.Hibernate查詢書寫出錯
F.Delete方法使用出錯
G.驗證器使用出錯
H.型別格式定義不正確..如日期時間型顯示為日期型
I.在WebWork的JavaScript中,好像不好直接使用'和"符號,也許要HtmlEncode後,才能用??,還是要UrlEncode?
J.全形作主鍵時,傳遞異常...
K.JS 除錯的時候,層次關係中,<!--註釋-->也是一個子物件..
L.驗證實現不精確..
M.再次注意,空值的包裝問題,再webWork中自動處理了,用其他框架時,要充分考慮
N.JDO物件需要及時更新,並且要及時調整相關的Bean
O.缺少JDO請及時加上
1.純JSP編寫時發生的錯誤
一般是沒有正確編譯,將編譯中的Java檔案放到IDE中編譯一下,就可以看到提示.
******************************************************************************************************
1、對Null字元進行String處理出錯
產生原因:資料庫中資料為空值,卻用字元處理函式進行處理了
後果:崩潰性錯誤
預防方法:
A.給資料庫中可能出現空值的欄位,加上預設值
B.提交時,用JS指令碼進行驗證
C.在處理可能是空值的字元時,用CheckNullStr(vValue) 對數值進行保護處理
D.對處理過程加上錯誤陷阱,防止出現崩潰性錯誤
2、傳遞引數時," ' 等字元造成問題
產生原因:處理" '等字元時,和Html中使用 " ' 等衝突,造成資料傳送失敗
後果:崩潰性錯誤
預防方法:
A.統一" '等符號的使用模式和策略
如 JS中,字串用""包起來 ' 需要用 \'代替
如傳遞查詢引數時,其中可能有 ' 和 % 需要特別的處理,所以用""包字串
B.在不丟失資料的情況下,根據情況使用
Server.HtmlEncode(vValue)
Server.UrlEncode(vValue)
C.對處理過程加上錯誤陷阱,防止出現崩潰性錯誤
3、資料庫裡面未設定主健
產生原因:構建資料庫時,未設定主健,
後果:造成查詢時,RecordCount顯示不正常,更新時得不到主健值,造成崩潰性錯誤
預防方法:
A.建表時仔細檢查主健是否建立,如沒有一定要建立
B.對處理過程加上錯誤陷阱,防止出現崩潰性錯誤
4、資料庫裡面欄位範圍設定太小
產生原因:欄位設定太小
後果:如發生越界情況,就造成崩潰性錯誤
預防方法:
A.仔細考慮欄位大小設定,如不是很密集的應用,可考慮儘量設定大一些
B.對處理過程加上錯誤陷阱,防止出現崩潰性錯誤
5、處理各個模組,因為Copy 程式碼,所以顯示的某些提示不準確
如工作郵件,提示為工作任務等
產生原因:硬編碼,Copy程式碼,粗心大意
後果:使用者感覺極差
預防方法:
A.仔細檢查,利用全文查詢,Windows的功能就可以,還可以用FrontPage
B.儘量使用一些比較模糊的提示語,可以具有通用性
C.將某些特定的提示進行常量定義,統一替換
6、單位名稱等不匹配
產生原因:硬編碼,Copy程式碼,粗心大意
後果:使用者感覺極差
預防方法:
A.仔細檢查,利用全文查詢,Windows的功能就可以,還可以用FrontPage
B.對使用的特定圖片檢查
C.將特定圖片和文字進行登記
C.將某些特定的名稱進行常量定義,統一替換,儘量利用Customer等通用常量,避免硬編碼
增加、編輯時常見錯誤
1、沒有進行,介面上的效驗問題
有人認為,這個不算錯誤,呵呵,那我也不說什麼了。很多情況下,初學的人會完全忽略這一塊,剛開始我就是的,還感覺這個就像程式把門的第一關口啊,最好能提前預防。
一般情況下,都是用javascript直接實現的,也有基於框架的後臺驗證,如DotNet和WebWork的驗證器等。通用的方法,是充分發揮正則驗證的潛力來解決好這一塊。
2、後臺效驗問題 JS+RPC OR Server
前臺的效驗完畢後,往往還需要進行後臺的邏輯效驗,如檢查是否重名等。一般是通過一組查詢來實現的。因為只是只讀的查詢,個人認為,怎麼實現都沒關係。通常是在後臺,提交資料庫前驗證。其實業可以通過ajax技術,在前臺驗證,隨著技術的發展,我想還是通過AJAX統一到前臺實現比較一致。
3、更新失敗返回問題
更新失敗的因素是多方面的,如資料連線斷開等。往往,很多人都沒有進行相關的保護,沒有相應的提示,或者提示返回後,客戶的輸入就丟失了。這些都是應該仔細考慮並解決的問題,很可惜,再大量學習各類框架和平臺後,相信很多人都沒有仔細的在這一塊加上那怕一點點保護。
4、編輯載入失敗返回問題
這個是個比較初級的問題,不過確實出現過,還是寫寫,看看自己忘了不.....
5、編輯載入,值還原問題,如回車丟失,空格丟失等
有時候,Html標籤寫的不好的時候,可能會丟值,如 回車,空格 ,<等符號
6、更新時,多步操作的事務保護機制不健全
這一點,本不該寫在此處,不過,我一直覺得這是個很重要的問題,所以還是加上。也許有人會說,我用Hibernate,這個問題就不存在了.....還是要重視啊,我見過有初學者,沒有很好的利用Hibernate的宣告事務標籤,或者根本不宣告...... 而且多步操作不寫在一個方法裡面,也不用手工的事務控制...寒,其實有些專案我自己都沒做到,因為各方面的原因@%^@#^@#^@^,悲哀ing.....
刪除常見錯誤
1、找不到記錄時錯誤
這個是個比較初級的問題,不過確實出現過,還是寫寫,看看自己忘了不.....
2、關聯資料不能自動檢查並返回資訊
對於一些有關聯的資料,應該通過檢查機制保護破壞性的刪除操作。
3、自動刪除關聯資料
這個對於一些POJO設計得非常好的系統,完全不用考慮的,呵呵不過,大家還是要很清晰的瞭解這種刪除的必要性,感覺初學者都忽略這些問題。
4、刪除時沒有清晰提示
通過JS保護只有一行程式碼,就可以給客戶一個避免錯誤操作的機會,何樂而不為呢,用框架的同仁們,你們這麼做了嗎?實際的系統,使用者不會忘了提這一點的。
檢視時錯誤
1、找不到資料時錯誤
這個是個比較初級的問題,不過確實出現過,還是寫寫,看看自己忘了不.....
2、一些值得顯示問題 如 回車、空格
加幾行轉碼的函式就可以避免,很多人忽略了,寒,如回車轉為<BR>,空格轉為
3、下拉表單資料的回顯問題 值-名對,顯示值,而不顯示名
下拉表單輸入時,大家都有解決方案了,回顯,就是一個查詢,請加上吧,不要讓自己眼睛不舒服。
分頁瀏覽時錯誤
1、找不到資料時的正確返回
這個是個比較初級的問題,不過確實出現過,還是寫寫,看看自己忘了不.....
2、翻頁後 條件保持問題(特別時有特殊字元時,如回車,"\"","\'"等)
要把條件傳遞到下一個頁面阿....
3、翻頁的效率問題
很多人沒仔細考慮,比如我自己,剛用Hibernate時,直接用一個完全查詢的HQL,取List.Count解決取總記錄的方法,結果,發現,這個查詢被執行了!!!現在改成一個專門取總行數的Count查詢...當然用專門對資料庫優化過的SQL和儲存過程,永遠是效率最高的方法
查詢時錯誤
1、查詢條件初始化問題
查詢條件如日期等,為什麼不給客戶一個最常用的時間段呢,可以避免使用者的操作
其實還有很多需要注意的細節容易出問題。如格式驗證...只讀欄位的控制.等等
一個完整的增刪改查應該有幾個部分的程式碼
1.新增載入
控制新增資料的預設初始化值
在Struct或者WebWork中,就是一個Action +一個檢視
2.新增提交
將使用者提交的新增資料,加入資料庫
在Struct或者WebWork中,就是一個Action
3.編輯載入
從庫中載入已有的某條資料方便編輯
在Struct或者WebWork中,就是一個Action +一個檢視
4.編輯提交
將使用者提交的修改資料,更新到庫中
在Struct或者WebWork中,就是一個Action
5.檢視記錄
從庫中載入已有的某條資料檢視
在Struct或者WebWork中,就是一個Action +一個檢視
6.刪除提交
將使用者指定的記錄刪除
在Struct或者WebWork中,就是一個Action
7.載入查詢
初始化查詢介面
在Struct或者WebWork中,就是一個Action+一個View
8.查詢提交
接受查詢介面的提交,並組合為查詢結果傳送給一個View
在Struct或者WebWork中,就是一個Action+一個View
也可以將請求轉交給分頁瀏覽頁面
9.分頁瀏覽
根據查詢條件和頁號,顯示特定資料頁的資料
在Struct或者WebWork中,就是一個Action+一個View
這裡,我沒有專門寫出formBean,個人認為FormBean只是一個工具
當然根據情況各種Action 和View可以進行各種整合,不過個人覺得,不管如何組合,這幾個環節都是很必要的,必須思路非常清晰才好。
附上我以前總結的一些常見的錯誤檢查表,給同事看的...
******************************************************************************************************
JAVA WEB應用常見的錯誤
在本系統中一些常見Bug和對策
1.Null指標錯誤
A.引用的Bean未在 Hibernate配置檔案,Spring配置檔案中正確的配置
B.呼叫的Session及Request 未能正確的取到
C.物件未初始化,或者在傳遞中失去了,往往使webWork託管的物件出現這種問題
D.未正確的寫上Getter,Setter方法
2.無任何提示的錯誤...
A.一般情況是HibernatePO執行的時候發生的錯誤,未將錯誤正確的丟擲..
B.轉入Error頁面採用Redirect模式,錯誤資訊不能顯示
其他
A.WebWork Action中未找到對應的對映
B.在彈出視窗中,Session丟失
C.Tomcat,MYSQL亂碼問題
在WebWork值得注意的是URL傳遞的引數,需要手工用toCN轉碼
Form傳遞的不需要
D.WebWork標籤的引用問題,Map request並不是和request對映的那個物件
有一個同名物件,但是型別是httpRequest的Request才是..
E.Hibernate查詢書寫出錯
F.Delete方法使用出錯
G.驗證器使用出錯
H.型別格式定義不正確..如日期時間型顯示為日期型
I.在WebWork的JavaScript中,好像不好直接使用'和"符號,也許要HtmlEncode後,才能用??,還是要UrlEncode?
J.全形作主鍵時,傳遞異常...
K.JS 除錯的時候,層次關係中,<!--註釋-->也是一個子物件..
L.驗證實現不精確..
M.再次注意,空值的包裝問題,再webWork中自動處理了,用其他框架時,要充分考慮
N.JDO物件需要及時更新,並且要及時調整相關的Bean
O.缺少JDO請及時加上
1.純JSP編寫時發生的錯誤
一般是沒有正確編譯,將編譯中的Java檔案放到IDE中編譯一下,就可以看到提示.
******************************************************************************************************
1、對Null字元進行String處理出錯
產生原因:資料庫中資料為空值,卻用字元處理函式進行處理了
後果:崩潰性錯誤
預防方法:
A.給資料庫中可能出現空值的欄位,加上預設值
B.提交時,用JS指令碼進行驗證
C.在處理可能是空值的字元時,用CheckNullStr(vValue) 對數值進行保護處理
D.對處理過程加上錯誤陷阱,防止出現崩潰性錯誤
2、傳遞引數時," ' 等字元造成問題
產生原因:處理" '等字元時,和Html中使用 " ' 等衝突,造成資料傳送失敗
後果:崩潰性錯誤
預防方法:
A.統一" '等符號的使用模式和策略
如 JS中,字串用""包起來 ' 需要用 \'代替
如傳遞查詢引數時,其中可能有 ' 和 % 需要特別的處理,所以用""包字串
B.在不丟失資料的情況下,根據情況使用
Server.HtmlEncode(vValue)
Server.UrlEncode(vValue)
C.對處理過程加上錯誤陷阱,防止出現崩潰性錯誤
3、資料庫裡面未設定主健
產生原因:構建資料庫時,未設定主健,
後果:造成查詢時,RecordCount顯示不正常,更新時得不到主健值,造成崩潰性錯誤
預防方法:
A.建表時仔細檢查主健是否建立,如沒有一定要建立
B.對處理過程加上錯誤陷阱,防止出現崩潰性錯誤
4、資料庫裡面欄位範圍設定太小
產生原因:欄位設定太小
後果:如發生越界情況,就造成崩潰性錯誤
預防方法:
A.仔細考慮欄位大小設定,如不是很密集的應用,可考慮儘量設定大一些
B.對處理過程加上錯誤陷阱,防止出現崩潰性錯誤
5、處理各個模組,因為Copy 程式碼,所以顯示的某些提示不準確
如工作郵件,提示為工作任務等
產生原因:硬編碼,Copy程式碼,粗心大意
後果:使用者感覺極差
預防方法:
A.仔細檢查,利用全文查詢,Windows的功能就可以,還可以用FrontPage
B.儘量使用一些比較模糊的提示語,可以具有通用性
C.將某些特定的提示進行常量定義,統一替換
6、單位名稱等不匹配
產生原因:硬編碼,Copy程式碼,粗心大意
後果:使用者感覺極差
預防方法:
A.仔細檢查,利用全文查詢,Windows的功能就可以,還可以用FrontPage
B.對使用的特定圖片檢查
C.將特定圖片和文字進行登記
C.將某些特定的名稱進行常量定義,統一替換,儘量利用Customer等通用常量,避免硬編碼