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