記得以前曾經有網友跟我們討論有關easyjweb的效率問題，大致意思是easyjweb用得少，沒有經過成熟專案的考驗，而struts應用案例比較多，所以用起更放心。我的看法是，easyjweb只是乙個mvc框架，在乙個j2ee應用中，mvc部分所承擔的任務是比較少的，真正影響系統效能的是系統中間層，即業務邏輯層與資料持久層。因此，有人問我，easyjweb及easydbo能否放心用於正式的商業專案中，我曾經的回答是：由於兩個專案都是測試階段，不建議使用，easyjweb基本不會出什麼問題（從系統的效率上來說），但easydbo的問題就難說了，因此不贊成把easydbo用於正式的商業專案中，等到正式發布1.0版本，有比較詳盡的文件後再用。
當然，要是大家都不用的話，easydbo肯定到不了1.0版本就得夭折。於是我在最近公司的乙個專案中還是大膽的用了。果不其然，過程還是比較痛苦的，遇到了很多對系統效能造成影響的問題，而且很多是非常致命的問題。下面簡單說明如下：
easydbo作為乙個orm系統，作為持久層的應用，對系統的效能影響非常大，若出了問題是非常致命的。特別是快取、事務、緩遲載入等。在最近我們公司的乙個專案中，由於使用easydbo作為orm系統，在開始一切都比較順利，由於使用的**生成工具，前期開發速度非常快，不過當資料到達幾十萬的時候，系統執行一段時間就會耗掉jvm記憶體，造成系統停止響應。汗啊，把頭都搞大了。。。。。今天把原始碼看了看，發現是沒有正常釋放資料資源的原因。修正後的**發到svn上了，有興趣的可以check out下來交流交流。
最讓人頭痛的是，由於easydbo專案當前沒有測試**，所以也不好對各個類進行單元測試，真是麻煩。因此，建議easydbo專案組對easydbo在資料來源的管理、配置上重新進行調，另外加強對快取部分的測試，特別是對大資料量測試。
現在的感受是： 做開源還真不容易啊，能長期、穩定參與的人也比較少。 唉!
最近，easyjf在招聘專職的開源工作人員了，不知道會不會有什麼改觀!
在乙個開源專案的開發中遇到的問題
記得以前曾經有跟我們討論有關easyjweb的效率問題，大致意思是easyjweb用得少，沒有經過成熟專案的考驗，而struts應用案例比較多，所以用起更放心。我的看法是，easyjweb只是乙個mvc框架，在乙個j2ee應用中，mvc部分所承擔的任務是比較少的，真正影響系統效能的是系統中間層，即業...
在乙個開源專案的開發中遇到的問題
記得以前曾經有跟我們討論有關easyjweb的效率問題，大致意思是easyjweb用得少，沒有經過成熟專案的考驗，而struts應用案例比較多，所以用起更放心。我的看法是，easyjweb只是乙個mvc框架，在乙個j2ee應用中，mvc部分所承擔的任務是比較少的，真正影響系統效能的是系統中間層，即業...
在乙個開源專案的開發中遇到的問題
記得以前曾經有跟我們討論有關easyjweb的效率問題，大致意思是easyjweb用得少，沒有經過成熟專案的考驗，而struts應用案例比較多，所以用起更放心。我的看法是，easyjweb只是乙個mvc框架，在乙個j2ee應用中，mvc部分所承擔的任務是比較少的，真正影響系統效能的是系統中間層，即業...