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