- 相關(guān)推薦
J2EE開(kāi)發(fā)原則
J2EE，作為開(kāi)發(fā)mission-critical的企業(yè)級應用的一整套規范的整合平臺，規范多、內容廣，從而給開(kāi)發(fā)J2EE應用帶來(lái)了很多“麻煩”。比如，為實(shí)現內容的RDBMS，我們可能的方法有JDBC、Entity Beans、JDO、O/R Mapping工具(TopLink、Hibernate)、XML-DBMS、JAXB等方法(其中一些方法不是J2EE規范所包含的)。
因此，為實(shí)現J2EE各層(至少有表示層、控制層、商業(yè)邏輯層等3層)以及層與層之間的耦合，J2EE系統架構師需要考慮的問(wèn)題會(huì )很多。加上，J2EE本身的快速發(fā)展，給架構、開(kāi)發(fā)具有工業(yè)強度的J2EE應用帶來(lái)一些難題。
1.結合商業(yè)需求選擇合理的架構
如果脫離商業(yè)需求，而單獨的討論技術(shù)本身的優(yōu)勢是不夠的。各項技術(shù)都有產(chǎn)生的特定背景，其中很多都是來(lái)自工業(yè)需求而觸動(dòng)的。一般而言，企業(yè)信息系統(EIS)都要求自己穩定、、可靠、高效、便于維護。同時(shí)，各個(gè)企業(yè)信息系統都有自己獨特的要求，可能有些時(shí)候需要考慮與原有遺留系統的集成，所以了解各個(gè)企業(yè)信息系統具體的商業(yè)需求對于整個(gè)系統的架構顯得很關(guān)鍵。
比如，如果待開(kāi)發(fā)的J2EE應用系統中使用到的數據大部分來(lái)自于外在數據源;而這些數據可能是通過(guò)JDBC直接從外在數據源導入到待開(kāi)發(fā)的J2EE系統的Database中。對于這種情形，如果在開(kāi)發(fā)過(guò)程中，僅僅使用JDBC來(lái)操作數據庫，對于小強度(并發(fā)訪(fǎng)問(wèn)用戶(hù)少、數據流量少)的情形，顯然是比較合適的;但如果，并發(fā)訪(fǎng)問(wèn)用戶(hù)較多、數據流量大，對Database層使用較為頻繁的情形，則顯得有些力不從心。
因此，對于這種需求，我們可以考慮采用Entity Beans with Caches。打個(gè)比方，在JBoss 3.2.1中對于Entity Beans的Cache策略有多種，這時(shí)可以考慮使用，即“Standard CMP 2.x EntityBean”，方式并采用“D”類(lèi)型的commit-option來(lái)保證Entity Beans的內容與數據源的同步，并使得系統的性能得到大大改善(同直接使用JDBC相比)。其中，可以將一些Entity Beans設置為read-only，以改善性能。當然，在這里也可以采用其他一些O/R Mapping技術(shù)，比如TopLink。
再比如，考慮這樣一種情形：如果待開(kāi)發(fā)的企業(yè)信息系統使用到的數據都是由系統本身生成和操作的，則建議采用：CMP Entity Beans技術(shù)。Entity Beans給大家的印象很壞，這可能與EJB 1.1給大家留下的壞映象有關(guān)吧。但是，EJB 2.0(或者說(shuō)2.1)得到了很大的改善，Local Interfaces、CMR、Read-Only、Session Fa?ade模式給Entity Beans注入了活力。當然，并發(fā)用戶(hù)多、數據流量很大時(shí)才會(huì )體現出使用Entity Beans的優(yōu)勢。其中，有一點(diǎn)很關(guān)鍵：要注重Entity Beans技術(shù)的性能調優(yōu)，各個(gè)應用都有自己的一套性能調優(yōu)方案。
對于JBoss 3.2.1，配置文件standardjboss.xml提供了Entity Beans技術(shù)調優(yōu)的入口。比如，Bean Lock策略的合理使用對于Entity Beans的調優(yōu)就顯得很重要。這樣使得，我們可以更加關(guān)注于系統的商業(yè)邏輯，而不只是底層的Database(EJB調優(yōu)處于EJB Container中，因此我們處在J2EE性能的高端，而不是底端，即Database層。同時(shí)，Database層的調優(yōu)使得J2EE系統的數據庫移植性大打折扣。)。
簡(jiǎn)而言之，要結合各個(gè)系統的特定需求和狀況給出具體的技術(shù)架構方案，而不能孤單的論述技術(shù)本身的好壞。
2.Framework的合理選用
設計模式在J2EE應用系統中扮演著(zhù)重要的角色。因此，有一個(gè)問(wèn)題擺在大家面前，是自己來(lái)實(shí)現具體的設計模式，還是借助于Third-party Framework。如果貴公司不大，或者說(shuō)公司不想在J2EE基礎應用Framework投入很多精力，選用現有的較為成熟的、穩定、與現有J2EE Specification兼容的技術(shù)框架會(huì )比較明智。
一般而言，Framework本身，或者說(shuō)J2EE平臺本身都是實(shí)現并優(yōu)化了具體的設計模式、規則，比如業(yè)務(wù)代理、Service Locator(包括Web Tier和EJB Tier各自的服務(wù)定位器，起到統一管理有限資源、Cache相關(guān)資源的作用，便于系統移植)、Front Controller、DAO等等�，F有的J2EE Framework比較豐富。比如：
Struts: 對于實(shí)現了Model 2類(lèi)型的Framework，對于現在以及將來(lái)(隨著(zhù)JSF規范、技術(shù)的成熟)，選用她是一種明智之舉。目前，Struts已經(jīng)發(fā)展到1.1版本。其內在的MVC主線(xiàn)、對后端數據操作方式?jīng)]有限定、集合了Apache Jakarta項目組的優(yōu)秀相關(guān)項目的精華，可謂是開(kāi)發(fā)J2EE應用的佳品。同時(shí)，對于具有.NET Web Forms功能的下一代J2EE平臺技術(shù)JSF而言，Struts本身可考慮到與JSF的兼容和集成性。比如，通過(guò)JSP呈現表示層、Servlet呈現控制層、EJB呈現數據層。各層之間，可以通過(guò)值對象、HTTP相關(guān)對象來(lái)通訊，實(shí)現J2EE相關(guān)技術(shù)的完美應用。
Log4j: 我想對于習慣采用“System.out.println(“”);”的讀者而言，Log4j是大家的福音。盡管 2 Standard Edition也具備java.util.logging包來(lái)保證日志的輸出，但Log4j的簡(jiǎn)單、高效、靈活已經(jīng)成了很多項目的選擇。日志，在某種程度上可以考驗系統的穩定性、正確性，所以采用可配置的Log4j(目前，Log4j已經(jīng)考慮到了與java.util.logging包的兼容性)是不會(huì )錯的。比如，JBoss 3.2.1本身就是借助于Log4j來(lái)管理日志的。
realMethods: 可能有些讀者還不知道這一款殺手锏。那好，這里就簡(jiǎn)要作一介紹。realMethods是一開(kāi)發(fā)J2EE應用的Framework，她不同于Struts(主要在于實(shí)現Model 2，J2EE應用前端);realMethods對于J2EE應用的各個(gè)層面都有詳盡、高效的支持。同時(shí)，realMethods以前還是商用軟件，現在已經(jīng)成為了Open Source的產(chǎn)品，因此現在可以參看其全部源代碼。
BC4J: 公司推出的用于的商業(yè)組件。其內容和外在的特點(diǎn)和優(yōu)勢，不言而喻。
當然，類(lèi)似的Framework很多很多。作為開(kāi)發(fā)J2EE應用的團隊而言，我們需要對各種Framework加以篩選，選擇適合項目需求、團隊、公司發(fā)展方向的框架。
一般情況下，待開(kāi)發(fā)的目標產(chǎn)品不宜采用過(guò)多的Framework。
其一，J2EE各個(gè)技術(shù)發(fā)展很快，過(guò)多的Framework使得系統的后續升級、維護不利;
其二，可以借鑒其中的好的一面，比如研究realMethods實(shí)現的相應的設計模式，并改造她以適合我們的項目需求;
其三，Framework本身會(huì )有變動(dòng)，如果選用過(guò)多，會(huì )給開(kāi)發(fā)團隊加重負擔，從而不利于項目管理。有選擇的使用現有的成熟Framework能提升大家的開(kāi)發(fā)效率、開(kāi)發(fā)水平。
3，開(kāi)發(fā)模式的選擇
開(kāi)發(fā)J2EE應用要求目標開(kāi)發(fā)人員能夠掌握其中的各種技術(shù)。但是，現實(shí)情況不是這樣。作為一個(gè)團隊，每個(gè)人都有自己不同的技能優(yōu)勢、興趣以及悟性。同時(shí)，J2EE本身需要體現社會(huì )分工。一般情況下，我們的開(kāi)發(fā)團隊不會(huì )有Specification所要求的各個(gè)開(kāi)發(fā)角色�，F實(shí)往往只有3種(也可能是兩種)：美工、JSP程序員、EJB程序員。面對這種分工，團隊更要注重溝通、交流，注重代碼的一致性。
一般情況下，團隊要盡量采用版本控制工具管理代碼、盡量做到每天都有一個(gè)完整的運行版本。經(jīng)過(guò)一段時(shí)間，團隊都會(huì )適應這種開(kāi)發(fā)模式。其中，版本控制工具一定要使用，便于代碼的管理、控制和備份。這其中會(huì )牽扯到很多層面。比如，開(kāi)發(fā)工具的選擇要考慮到版本控制工具的使用、建模工具的合理使用有助于團隊有效的溝通和交流。
基于現有的開(kāi)發(fā)模式，個(gè)人認為這樣3套方案不錯。第一，采用Together作為建模工具、采用JBuilder作為IDE工具、采用VSS(或者CVS)作為版本控制工具、采用JBoss作為開(kāi)發(fā)J2EE應用開(kāi)發(fā)階段的。第二，采用WebSphere Studio整套工具。第三，采用Eclipse(或者JCreator)、Ant、XDoclets作為開(kāi)發(fā)工具。
當然，手工完成J2EE應用的編寫(xiě)、編譯、打包、部署、更能使開(kāi)發(fā)者理解各個(gè)開(kāi)發(fā)階段的具體細節。但本人認為，只要開(kāi)發(fā)者有這種關(guān)注具體細節的態(tài)度，選用功能強大的建模、開(kāi)發(fā)工具是明智的。開(kāi)發(fā)工具不能提高開(kāi)發(fā)人員的開(kāi)發(fā)技能，但是她能夠引導開(kāi)發(fā)人員正確的開(kāi)發(fā)方向。比如,JBuidler 9 Enterprise提供的EJB精靈具有的“Struts + EJB + Session Fa?ade + Value Object”等功能呈現了業(yè)界廣泛應用的J2EE構架方式。
4，注重各個(gè)階段的工作
測試工作往往是很多項目經(jīng)理忽視，不愿意去花費時(shí)間、費用的內容，因為那樣會(huì )增加項目的成本。但是，他們忽視了，項目的完成質(zhì)量往往對項目的成本有很大的關(guān)系。比如，如果軟件質(zhì)量很差，并沒(méi)有經(jīng)歷測試階段，其后期部署、運行所帶來(lái)的費用會(huì )遠遠超過(guò)前期的費用。
測試是分階段的。單元測試，比如借助于JUnit，來(lái)保證功能正確等內容。集成測試，來(lái)保證系統沒(méi)有內存泄漏等內容。其中，Optimizeite Suite Enterprise對于完成Profiler、Code Coverage、Thread Debugger等內容很有幫助。我記得，我寫(xiě)的一個(gè)Swing桌面應用存在內容泄漏，但是想了很多辦法都沒(méi)有解決問(wèn)題。后來(lái)，采用Profiler獲得了答案。因此，現在開(kāi)發(fā)應用，我們很多時(shí)候都采用Optimizeite Suite Enterprise作為測試工具。尤其是，在做集成測試過(guò)程中，檢查系統的內存泄漏、性能很有幫助。
測試是分類(lèi)型的。壓力測試、性能測試。就目前對支持J2EE應用的測試而言，并沒(méi)有很好的測試工具。但是，一般情況下，借助于Rational Robot也能夠取得不錯的效果。
當然，成功開(kāi)發(fā)J2EE應用的因素有很多。比如，Entity Beans的成功應用很大程度上與底層Database的設計有關(guān)系(如果表結構設計設計的不合理，將導致Entity Beans性能的急劇下降);如何最大化挖掘、提升團隊各個(gè)成員的J2EE技能。等等這些，設計面很廣。希望對你有幫助。
【J2EE開(kāi)發(fā)原則】相關(guān)文章：
J2EE項目開(kāi)發(fā)風(fēng)險匯總08-03
Eclipse j2ee開(kāi)發(fā)環(huán)境的搭建07-27
J2EE架構與開(kāi)發(fā)簡(jiǎn)答題10-31
Java Web開(kāi)發(fā)和J2EE的區別07-07
J2EE項目開(kāi)發(fā)10大風(fēng)險盤(pán)點(diǎn)08-26