?????????先說一下openfans最早版本的整體設(shè)計。首先是用Equinox直接new出項目來，它默認是springmvc+spring+hibernate再加-上一些常用的組件，如sitemesh，common-validator，dwr等。而這些都是我們想要的。?
?????????有了這個大的框架，我們可以進行業(yè)務(wù)建模了，我們采用的是領(lǐng)域模型驅(qū)動的設(shè)計方案。首先考慮的是對象以及對象間的關(guān)聯(lián)，我們也沒用什么建模工具和自動生成工具，-先自己寫java類，寫好屬性，用eclipse生成get和set。然后手寫hibernate的hbm配置文件，有點土，這也是我第一正式的使用hiber-nate。開始我用了dao模式，寫了好多dao，后來和oofrank討論，一直認為hibernate就是我們的持久層，完全沒有必要為了移植性（如將來使-用ibatis）而引入dao。所以拋棄了dao模式，而由一個fa?ade處理持久。這樣的設(shè)計跟一般的三層模型略有不同，hibernate就是我們的持久-層，然后通過一個fa?ade提供對上層的接口。領(lǐng)域模型和mvc中的c充當我們的業(yè)務(wù)層。我們的對象不是貧血模型，而是有能力的。當然現(xiàn)在這種能力更多是對象-間的關(guān)聯(lián)，而對持久層無能為力，但也已經(jīng)方便了很多。Controller現(xiàn)在具有較多的功能，它能調(diào)領(lǐng)域?qū)ο螅材苤苯邮褂胒a?ade。然后是jsp+js-tl+el做純粹的展現(xiàn)層。C和V的分類原則是這樣的：一類是查看，一類是form提交。所有查看由一個viewController統(tǒng)一處理（這樣增加了一些-耦合，但效果還可以），一個對象的增、刪、改由一個formController處理。?
???????????有了這些設(shè)計原則，做起來倒是很快，幾天就核心功能出來了。對于數(shù)據(jù)庫，只要建一個庫就行，其余的如建表，改表等都由hibernate來自動幫你完成，數(shù)據(jù)庫-就是在寫hbm時關(guān)心下，其它完全對我們透明，感覺還是挺爽的。?最初版一共就20幾個類，完成了很多的功能，可以具體看
www.openfans.org???????????下一篇寫怎么使用maven和tomcat，讓openfans在自己機器上跑起來。先去吃飯了，^_^。大家有任何疑問和好的改進意見，都可以提，跟帖。
本網(wǎng)站旨在推動opensource軟件在中國的傳播和使用。應(yīng)用web2.0的思想，提倡大家都來參與和有收獲有貢獻的風氣。注冊后就可以直接登錄（將來需發(fā)email進行驗證），登錄近來就可以進行所有的操作了。
?????操作很簡單，先可以點擊上面的修改用戶鏈接，補充自己的信息（現(xiàn)在只要填入blog地址、簡單描述和所在地），這樣能夠讓其它用戶更好的了解你，還可以加一個你喜歡的圖像上傳（現(xiàn)在大小限制在10k以內(nèi)）。
??????點擊推薦軟件鏈接，可以推薦你喜歡的開源軟件。填入名稱，主頁，加上你的介紹或官方的介紹，然后給它個圖標，就可以了。圖標可以在它的主頁上找到，然后將其url拷貝下來，就可以了。
?????在瀏覽軟件時，你可以隨時增加認為與其相關(guān)的標簽（我們把軟件認為是一種特殊的標簽）。標簽標題是不帶空格的，我們可以填入用空格分割的多個標簽，系統(tǒng)會依次增加這些標簽關(guān)聯(lián)。如hibernate，你認為它是持久層，也可以認為是O/Rmapping，已經(jīng)關(guān)聯(lián)的標簽也可以再加，我們會增加其關(guān)聯(lián)度。一個標簽下的相關(guān)標簽會按關(guān)聯(lián)度從高到低排列。
?????更重要的是你說明自己對這個軟件的使用情況，如熟練掌握、正在使用還是準備使用。簡單的點擊，會給軟件和你增加有用的信息。我們會看到一個軟件有多少人熟練掌握，有多少人正在使用，在進行同類軟件橫向比較時非常有用。而如果你在準備使用一個軟件時，就可以看看有誰熟練掌握了這個軟件，可以看他（她）的blog，或直接跟他（她）聯(lián)系，更快的掌握這個軟件。
?????如果你有好的心得體會或看到網(wǎng)上有好得相關(guān)文章，也可以在瀏覽標簽的頁面，點擊發(fā)表文章鏈接，跟大家進行分享。別人也許就因為你的一篇文章快速入門了呢，呵呵！
?????將來還會有更多更好更酷的功能出來，我們永遠會從用戶角度出發(fā)，力求做到最好的用戶體驗。歡迎進入openfans的世界！
注冊網(wǎng)站
www.openfans.org以及
www.openfans.net(現(xiàn)在www.openfans.net開通了
)，提供對開源軟件的介紹和評論。應(yīng)用web
2.0思想，體現(xiàn)社區(qū)自管理的原則，提倡對開源軟件學(xué)習(xí)和交互。期望成為中國開源軟件介紹和交流的主流平臺之一，為開源軟件在中國的傳播和使用貢獻自己的力量。
roadmap（暫定）：
0.1（4月底完成）--注冊，登陸，權(quán)限管理，標簽功能，發(fā)表軟件介紹和文章
0.5（5月底完成）--評分體系，同城，小組和朋友管理
0.8（7月底完成）--sns功能，投票功能
1.0（9月底完成）--開始形成專家小組，提供項目外包和咨詢管理平臺
更多--隨著平臺的使用和更多的成員加入，不斷加入新的功能
同時啟動開源項目openfans，使用開源軟件：eclipse,
maven2, spring(包括spring mvc), hibernate,
mysql,common-validator,sitemesh.....
目的是提供web2.0應(yīng)用的基本模型，同步在www.openfans.net上進行驗證和使用，并能夠方便的移植到其它領(lǐng)域。
目前項目在sourceforge上，由pesome和oofrank共同管理。0.1版基本完成。
cvs -d:pserver:anonym...@cvs.sourceforge.net:/cvsroot/openfans login
希望參與開發(fā)的同學(xué)請mailto:pes...@gmail.com，簡單介紹自己并注明在sf上的用戶名。
在google上開了一個站務(wù)論壇：http://groups.google.com/group/openfans
歡迎大家多來訪問，推薦軟件和文章，方便大家更快更好的找到自己最需要的東西！
項目組對log和exception的討論結(jié)果。希望更多的人參與討論。
1 log
1.1 用log.error表示系統(tǒng)級錯誤
1.2 用log.warn表示應(yīng)用級錯誤
1.3 服務(wù)初始化或結(jié)束用log.info
1.4 用log.debug替代out，debug要判斷isDebugEnable
1.5 用log.warn("",e)替代e.printstack
1.6 用log4e生成log相關(guān)代碼
1.7 Log信息要保證可讀性，需記錄現(xiàn)場信息，如當前處理id等
2 exception
2.1 try catch內(nèi)的代碼不要太長
2.2 因為性能原因，try catch少放循環(huán)內(nèi)
2.3 盡量避免catch(Exception)這樣的寫法
2.4 不同模塊定義不同的exception
2.5 建議創(chuàng)建應(yīng)用的基類exception，特別是有定義error code需要的應(yīng)用
2.6 只要catch就要log error message
2.7 catch并封裝成另一種exception，如果不nest原來的exception就要log stackTrace
2.8 持久層throw dataAccessException，業(yè)務(wù)層throw checked exception，展現(xiàn)層只顯示exception信息
2.9 規(guī)范的exception流程定義如下：
業(yè)務(wù)層不需處理的runtime exception，由展現(xiàn)層定義的exception controller捕獲，交給相應(yīng)的error頁面顯示并記錄stack信息。業(yè)務(wù)層捕獲下層的exception，并封裝成業(yè)務(wù)層的checked exception，如果nest所捕獲的exception，則僅log error message，如果不nest就需要用log.warn(“”,e)記錄stack信息。展現(xiàn)層捕獲業(yè)務(wù)層的exception，應(yīng)由處理業(yè)務(wù)層exception的error頁面來處理。
對spring框架和開發(fā)模式進行了驗證。大家有什么問題或好的建議，請回復(fù)，大家一起討論！
一、 項目目標及完成情況
|
目標 |
完成情況 |
|
技術(shù)驗證和推廣 |
完成較好。
1． 共有7人實際參與項目開發(fā)，我們引入maven2作為構(gòu)建工具，eclipse作為ide環(huán)境。大家都能在很短的時間初始化項目，并快速掌握各自需要的技術(shù)（如spring，spring mvc等）進行開發(fā)。
2． 對分層開發(fā)的模式也進行了探討，證明它是可行的：可以各層并行開發(fā)，提高開發(fā)效率；而通過分層可以隔離關(guān)注點，使得各層開發(fā)人員可以只關(guān)注本層相關(guān)技術(shù)和接口，減輕開發(fā)人員負擔，提高效率。
3． 在項目活動中碰到一些技術(shù)難點，我們將解決方案文檔化，然后項目內(nèi)共享，這樣能在碰到同樣問題時快速解決。現(xiàn)在還是碰到問題才解決，以后需要建立預(yù)研機制，較早發(fā)現(xiàn)可能出現(xiàn)的難點，盡早解決，避免對項目進展產(chǎn)生影響。
4． 平臺還處于建設(shè)階段，對項目的支持還不夠，需要形成一些通用的組件。 |
|
過程和管理實施 |
有待提高。
1． 測試1.0版已發(fā)布，目前開發(fā)1。1版，完善分頁功能和采用更好的驗證方式。由于對規(guī)范開發(fā)的項目周期估計不足，加上管理上的一些問題，導(dǎo)致項目有所延期，需要對實際的項目開發(fā)進行量化分析，確立比較準確的人員和時間計劃。
2． UC文檔規(guī)范和編碼規(guī)范等的引入，為項目提供了較好的支持。
3． 在實施中比較缺乏必要的文檔支持，如設(shè)計文檔等；同時各層的接口定義也出現(xiàn)較多問題，導(dǎo)致一些開發(fā)瓶頸的出現(xiàn)，這都需要在正式迭代中改進。 |
|
系統(tǒng)功能 |
完成較好。
1． 完成了UC文檔確定的功能點，頁面美觀，使用方便，能給用戶較好的頁面體驗。
2． 采用較好的面向?qū)ο笤O(shè)計，能提供一定的可重用性和擴展性。 |
二、展現(xiàn)層總結(jié)
經(jīng)驗與教訓(xùn)
1. SpringMVC是一個簡潔、標準的MVC實現(xiàn)，結(jié)構(gòu)清晰，功能強大（主要體現(xiàn)在對日常WEB開發(fā)中可能遇到的各種常見問題的解決方案），有一定學(xué)習(xí)曲線，但是有其它MVC框架基礎(chǔ)的開發(fā)人員可以較快上手；
2. 根據(jù)業(yè)務(wù)功能盡早確定接口，接口由展現(xiàn)層確定，由業(yè)務(wù)層實現(xiàn)；
3. 合理選擇Controller可以減少開發(fā)工作量，前提是充分理解每種Controller的處理機制及其回調(diào)方法細節(jié)，Controller的編寫更多的精力主要花在校驗、出錯處理上；
4. 頁面工作量很大，特別是需要比較復(fù)雜javascript的頁面；
5. UI的流轉(zhuǎn)設(shè)計等對于Controller的編寫和業(yè)務(wù)層的接口有著很大的影響，應(yīng)盡早明確，否則會產(chǎn)生較大的返工；
6. 展現(xiàn)層開發(fā)可以與業(yè)務(wù)層同步進行，推薦確定接口后，就編寫業(yè)務(wù)層接口的mock實現(xiàn)，放在展現(xiàn)層的test包內(nèi)，同時寫單獨的測試用spring配置文件；
待解決問題
1. Controller是否應(yīng)寫test case，本次開發(fā)未做；
2. 如何減少校驗的工作量，對于有業(yè)務(wù)邏輯的服務(wù)端校驗如何實現(xiàn)，是否需要采用一些validator框架，如sun的JEF的validator組件，目前我們進行了研究，通過使用commons validator組件能夠較方便的實現(xiàn)validator；
三、業(yè)務(wù)層總結(jié)
經(jīng)驗與教訓(xùn)：
1. Spring，iBatis的應(yīng)用還是很成功的，學(xué)習(xí)曲線比較平滑，好的框架好掌握；
2. 比較重視測試，編寫很多測試案例，并頻繁使用maven運行所有測試，使得問題能夠及早發(fā)現(xiàn)，保證了各層能夠快速成功集成
3. 對于很多問題都需要經(jīng)過各層間的討論來確定；
4. 接口由展現(xiàn)層定義，由業(yè)務(wù)層實現(xiàn)；
5. 持久層數(shù)據(jù)模型和領(lǐng)域模型是有區(qū)別的，但簡單的情況下可以合二為一；
6. Fa?ade模式還是很有價值的；
7. 一些開源軟件的使用需要比較小心，如iBatis的null的問題等，如果處理不當會花費較多的人力物力，需要技術(shù)較強的人對開源軟件花費一定時間進行源碼級的研究，才能找出較好的解決方案；
8. 認識到設(shè)計的重要性，需要對前置、后置條件等進行分析；
9. 數(shù)據(jù)類型分析簡單，造成數(shù)據(jù)庫設(shè)計對業(yè)務(wù)層產(chǎn)生不良影響；
待解決問題：
1. 溝通不夠，需要建立溝通渠道，是否可以有專門的場合和時間討論項目中的進度和問題；
2. 計劃不明確，對于要完成哪些功能，完成到什么程度，沒有明確的定義，需要設(shè)置里程碑目標。在正式迭代開始前，要明確每次迭代的任務(wù)和目標，需要結(jié)合業(yè)務(wù)需求進行計劃；
四、持久層總結(jié)
經(jīng)驗與教訓(xùn)：
1． 通過代碼生成工具，能夠大大提高開發(fā)效率；
2． 工具使用者要求對ibatis和sql比較了解；
3． 在使用過程中對工具進行了完善，這對正式使用工具提供了保證；
4． 與業(yè)務(wù)層的接口，應(yīng)該由業(yè)務(wù)層確定，由持久層實現(xiàn)，而不是由持久層決定；
待解決問題：
1． 持久層的測試該如何進行，才能真的有用；
2． 一些通用功能如分頁代碼生成，還在開發(fā)中；
今天跟SUN的高級工程師有了些交流，感觸頗多。首先要談到它的一個產(chǎn)品（其實不能叫產(chǎn)品）JEF，也就是Java Enterprise Framework。JEF可以說是很多框架和組件的有機結(jié)合，有opensource的，有商業(yè)的，也有sun自己寫的，其實也是SUN在多個大規(guī)模項目中不斷實踐的基礎(chǔ)上發(fā)展起來的。它通過定義良好的分層和封裝，能夠提供應(yīng)用開發(fā)非常堅實的基礎(chǔ)。下圖是JEF的整體架構(gòu)圖：
有機會再進行對它整體架構(gòu)和各個組件功能的詳談吧。
再談一談對真正的系統(tǒng)架構(gòu)師的認識。JEF的2個主要設(shè)計者我都見過了，都是香港人，都溫文爾雅，學(xué)識淵博，經(jīng)驗豐富。能夠聆聽它們對軟件架構(gòu)的理解，對項目實際問題的分析和解決，真的是受益匪淺，對自己將來進行設(shè)計時思考問題的深度和廣度都有很大的提高。這才是真正的架構(gòu)師！他需要對各種框架，組件都了如指掌，在面對具體的項目需求時能正確的選擇最適用的技術(shù)；他需要對軟件整體架構(gòu)有清晰的認識和理解，知道在面對實際項目時該使用何種架構(gòu)，包括thin client還是rich client，with EJB還是without EJB等等；他需要有一種嚴謹求證的性格，對任何東西不是盲目下結(jié)論，而是根據(jù)具體的分析和實證進行取舍。。。。。。通往真正的架構(gòu)師的路還很長，需要經(jīng)歷的項目，需要做的事情還很多。我們不能盲目尊大（拿spring＋hibernate做個小項目就以為很牛），也不能喪失信心（經(jīng)驗和領(lǐng)會都是靠項目做出來的）。我們應(yīng)該時刻保持向上的心態(tài)，去主動參與項目，去溝通，去交流，去總結(jié)，去思考。即使將來成不了真正的架構(gòu)師，我們也可以自豪的說：“我每一步都是踏實的走下來的，我每一個項目都是用心在做的，我的代碼都是注釋詳實，簡單易懂，為后來者提供很好的可重用基礎(chǔ)的而不是被人咒罵的，我做的是可用的軟件而不是垃圾軟件。”希望與所有有志于成為真正的系統(tǒng)架構(gòu)師的同學(xué)共勉。
摘要: 項目很小，主體部分也完成的差不多了，但麻雀雖小，五臟具全，我在其中用到了spring的IoC和transaction管理，也用到了簡單的AOP功能，同時使用了spring mvc，下面我對它們做一些總結(jié)，也跟和我一樣剛剛踏入spring大門的兄弟們探討探討：
（一）spring IoC探討
先還是談?wù)剆pring IoC的使用。IoC也就是控制反轉(zhuǎn)，即由容器來調(diào)用你的代碼，而你不用去使用容器的...
閱讀全文
今天忙了一天，收獲不小。到公司接到個小項目，需求很簡單，時間也很寬松，我就想用spring＋hibernate來做，其實有點殺雞用牛刀的味道，但我覺得能通過實踐來學(xué)習(xí)spring和hibernate，也還是不錯的。
spring和hibernate我也是剛學(xué)，各看了本書，然后搞了搞spring的sample，就是那個jpetstore和petclinic，一個是用ibatis，一個用hibernate做persistence層。同時有一個剛進公司的人跟著我做，我也就得先把項目初始化好，寫好配置文件，分好包和層次結(jié)構(gòu)，然后放cvs上。既然用spring＋hibernate，配置文件肯定是很多的，我基本是參照petclinic，分了dao, dao.hibernate, model, model.logic, service, web這幾個包，配置文件定義了applicationContext.xml，app-servlet.xml(我用spring mvc) , log4j.properties，jdbc.properties, mail.properties，說到spring的配置文件，其實也不復(fù)雜，搞懂了它的IoC（DI）和AOP就很容易配了，層次定義清楚，在頭腦中對誰ref誰有概念，基本就不大會配錯了。錯了也沒關(guān)系，它的log功能強大，定義好log4j，出了什么錯都能有詳細的記錄。我搞spring的sample時就是把這個配置改改，那個刪掉，自己寫個類，替換它的。。。。。。這樣很快就對它的配置文件有了深刻的理解。這次算是我第一個正式用spring的項目，但因為前面在理論上和零星的實踐中對它有了較深的認識，也就大大降低了項目的風險（技術(shù)預(yù)研真的很重要啊！）。
雖然是小項目，但也得規(guī)范一下，定好項目計劃，統(tǒng)一大家使用的工具和環(huán)境，簡單交代編程的注意事項，如代碼規(guī)范，cvs的使用，多寫test類等。我們采用eclipse3.1+ myeclipse+tomcat5+mysql作為各自的開發(fā)和單元測試環(huán)境，上線使用websphere5+db2。我是要求先在mysql上能跑，然后能方便的遷移到db2上的，這樣方便進行單元測試，也能在事實上與數(shù)據(jù)庫解耦合，用hibernate很容易做到這一點。
但要能順利的上線到websphere5，我就沒什么把握了，畢竟它還是使用ibm 的jdk1.3，而且很多東西跟tomcat不同，更會不會有什么lib沖突等問題。我先把兼容性測試放在了開發(fā)的前面，否則在tomcat上開發(fā)好了，websphere不支持或出現(xiàn)難以解決的問題，就麻煩了，嚴重的可能要推倒重來。因為沒在實際項目中使用過spring，周圍又沒什么人可問（我畢業(yè)一年多，沒有高手指導(dǎo)，全靠自學(xué)和實際項目中領(lǐng)悟），所以有這些疑問也是正常的。不管如何，先把項目在tomcat上跑起來再說。改了一通配置文件，配好tomcat的數(shù)據(jù)源，往mysql加一個最簡單的表（id一個字段），寫了2張最簡單的jsp（測試spring mvc的multiaction用），一個jsp顯示從數(shù)據(jù)庫獲得的id。開啟和關(guān)閉幾次tomcat（我比較粗心大意，配錯好幾處），id就能在頁面上顯示了。Tomcat上基本配置完成，這也忙了個3、4個小時。
然后就是做兼容性測試了。我們有個websphere的測試環(huán)境，先把項目deploy到它上面。測試環(huán)境沒用ND，我先deploy到server1上，這樣能重啟應(yīng)用。Deploy完成，頁面都出不來，500錯，應(yīng)用就沒起來。先看日志，哇！一堆錯。分析日志，好像是先裝載的DispatcherServlet, 然后才是ContextLoaderServlet，當然出問題了，不過至少說明它找到了lib下的spring.jar也能work。我使用的Listener而不是Servlet來load context，估計是這個原因?qū)е碌模?/SPAN>tomcat工作正常，websphere對Listener就不保證先啟動了。于是改成使用Servlet，tomcat測試通過，我將改過的web.xml覆蓋服務(wù)器(這里要覆蓋2個地方，一個是應(yīng)用下的，還有一個config/cells…..下的)， 重啟應(yīng)用，再看日志，還是錯。不過這次是先啟動ContextLoaderServlet了，但一上來就錯了，報錯：javax.naming.NamingException: Attempted to use a 4.0 DataSource from a 2.3 (or higher) servlet。這不是spring的問題，呵呵！我用的數(shù)據(jù)源V4，結(jié)果用了j2ee2.3，再改web.xml，頭上改成用j2ee2.2，再覆蓋，再啟應(yīng)用。這次首頁出來了，看日志，一切正常。呵呵！沒那么多問題嘛，jdk1.3照樣跑最新的spring和hibernate。
今天從零開始把spring和hibernate跑了起來，也算是一次不錯的實戰(zhàn)，就作為spring+hibernate實戰(zhàn)的第一篇吧，接下來幾天，我在項目中的體會也會記錄下來，當成一個一個系列吧。
摘要: 這篇文章源自剛開發(fā)的一個小項目。項目中并未使用hibernate，但我還是要把它放在hibernate欄下。理由很簡單，技術(shù)是死的，而人是活的，能熟練的使用一項技術(shù)不算什么，但能恰當?shù)倪x擇相應(yīng)的技術(shù)，甚至自己想出辦法來優(yōu)雅的解決實際問題，就需要一定的積累了。而這種積累就來源自項目實踐和對各種技術(shù)其實質(zhì)的理解。我記得在某個論壇上某人（名字忘了）說過一句話：如果學(xué)習(xí)hibernate只是學(xué)會了怎么ma...
閱讀全文