對spring框架和開發模式進行了驗證。大家有什么問題或好的建議,請回復,大家一起討論!
一、 項目目標及完成情況
目標 |
完成情況 |
技術驗證和推廣 |
完成較好。
1. 共有7人實際參與項目開發,我們引入maven2作為構建工具,eclipse作為ide環境。大家都能在很短的時間初始化項目,并快速掌握各自需要的技術(如spring,spring mvc等)進行開發。
2. 對分層開發的模式也進行了探討,證明它是可行的:可以各層并行開發,提高開發效率;而通過分層可以隔離關注點,使得各層開發人員可以只關注本層相關技術和接口,減輕開發人員負擔,提高效率。
3. 在項目活動中碰到一些技術難點,我們將解決方案文檔化,然后項目內共享,這樣能在碰到同樣問題時快速解決。現在還是碰到問題才解決,以后需要建立預研機制,較早發現可能出現的難點,盡早解決,避免對項目進展產生影響。
4. 平臺還處于建設階段,對項目的支持還不夠,需要形成一些通用的組件。 |
過程和管理實施 |
有待提高。
1. 測試1.0版已發布,目前開發1。1版,完善分頁功能和采用更好的驗證方式。由于對規范開發的項目周期估計不足,加上管理上的一些問題,導致項目有所延期,需要對實際的項目開發進行量化分析,確立比較準確的人員和時間計劃。
2. UC文檔規范和編碼規范等的引入,為項目提供了較好的支持。
3. 在實施中比較缺乏必要的文檔支持,如設計文檔等;同時各層的接口定義也出現較多問題,導致一些開發瓶頸的出現,這都需要在正式迭代中改進。 |
系統功能 |
完成較好。
1. 完成了UC文檔確定的功能點,頁面美觀,使用方便,能給用戶較好的頁面體驗。
2. 采用較好的面向對象設計,能提供一定的可重用性和擴展性。 |
二、展現層總結
經驗與教訓
1. SpringMVC是一個簡潔、標準的MVC實現,結構清晰,功能強大(主要體現在對日常WEB開發中可能遇到的各種常見問題的解決方案),有一定學習曲線,但是有其它MVC框架基礎的開發人員可以較快上手;
2. 根據業務功能盡早確定接口,接口由展現層確定,由業務層實現;
3. 合理選擇Controller可以減少開發工作量,前提是充分理解每種Controller的處理機制及其回調方法細節,Controller的編寫更多的精力主要花在校驗、出錯處理上;
4. 頁面工作量很大,特別是需要比較復雜javascript的頁面;
5. UI的流轉設計等對于Controller的編寫和業務層的接口有著很大的影響,應盡早明確,否則會產生較大的返工;
6. 展現層開發可以與業務層同步進行,推薦確定接口后,就編寫業務層接口的mock實現,放在展現層的test包內,同時寫單獨的測試用spring配置文件;
待解決問題
1. Controller是否應寫test case,本次開發未做;
2. 如何減少校驗的工作量,對于有業務邏輯的服務端校驗如何實現,是否需要采用一些validator框架,如sun的JEF的validator組件,目前我們進行了研究,通過使用commons validator組件能夠較方便的實現validator;
三、業務層總結
經驗與教訓:
1. Spring,iBatis的應用還是很成功的,學習曲線比較平滑,好的框架好掌握;
2. 比較重視測試,編寫很多測試案例,并頻繁使用maven運行所有測試,使得問題能夠及早發現,保證了各層能夠快速成功集成
3. 對于很多問題都需要經過各層間的討論來確定;
4. 接口由展現層定義,由業務層實現;
5. 持久層數據模型和領域模型是有區別的,但簡單的情況下可以合二為一;
6. Fa?ade模式還是很有價值的;
7. 一些開源軟件的使用需要比較小心,如iBatis的null的問題等,如果處理不當會花費較多的人力物力,需要技術較強的人對開源軟件花費一定時間進行源碼級的研究,才能找出較好的解決方案;
8. 認識到設計的重要性,需要對前置、后置條件等進行分析;
9. 數據類型分析簡單,造成數據庫設計對業務層產生不良影響;
待解決問題:
1. 溝通不夠,需要建立溝通渠道,是否可以有專門的場合和時間討論項目中的進度和問題;
2. 計劃不明確,對于要完成哪些功能,完成到什么程度,沒有明確的定義,需要設置里程碑目標。在正式迭代開始前,要明確每次迭代的任務和目標,需要結合業務需求進行計劃;
四、持久層總結
經驗與教訓:
1. 通過代碼生成工具,能夠大大提高開發效率;
2. 工具使用者要求對ibatis和sql比較了解;
3. 在使用過程中對工具進行了完善,這對正式使用工具提供了保證;
4. 與業務層的接口,應該由業務層確定,由持久層實現,而不是由持久層決定;
待解決問題:
1. 持久層的測試該如何進行,才能真的有用;
2. 一些通用功能如分頁代碼生成,還在開發中;