注：目前J2EE的開發工作網絡上討論的熱火朝天，各種新技術層出不窮，當然了我們這些新手看的也是一頭霧水，感覺的j2ee涉及到的技術太廣，各種framework令人眼花繚亂，今天看了這篇介紹性文章，感覺不錯，和大家分享一下文章的主要觀點。（其中提到的一些技術或規范可能比較老了，主要是學習一下作者的觀點）
1.結合商業需求選擇合理的架構
一般而言，企業信息系統（EIS）都要求自己穩定、安全、可靠、高效、便于維護。同時，各個企業信息系統都有自己獨特的要求，可能有些時候需要考慮與原有遺留系統的集成，所以了解各個企業信息系統具體的商業需求對于整個系統的架構顯得很關鍵。
比如，如果待開發的J2EE應用系統中使用到的數據大部分來自于外在數據源；而這些數據可能是通過JDBC直接從外在數據源導入到待開發的J2EE系統的Database中。對于這種情形，如果在開發過程中，僅僅使用JDBC來操作數據庫，對于小強度（并發訪問用戶少、數據流量少）的情形，顯然是比較合適的；但如果，并發訪問用戶較多、數據流量大，對Database層使用較為頻繁的情形，則顯得有些力不從心。因此，對于這種需求，我們可以考慮采用Entity Beans with Caches。打個比方，在JBoss 3.2.1中對于Entity Beans的Cache策略有多種，這時可以考慮使用，，即“Standard CMP 2.x EntityBean”，方式并采用“D”類型的commit-option來保證Entity Beans的內容與數據源的同步，并使得系統的性能得到大大改善（同直接使用JDBC相比）。其中，可以將一些Entity Beans設置為read-only，以改善性能。當然，在這里也可以采用其他一些O/R Mapping技術，比如TopLink。
再比如，考慮這樣一種情形：如果待開發的企業信息系統使用到的數據都是由系統本身生成和操作的，則建議采用：CMP Entity Beans技術。Entity Beans給大家的印象很壞，這可能與EJB 1.1給大家留下的壞映象有關吧。但是，EJB 2.0(或者說2.1)得到了很大的改善，Local Interfaces、CMR、Read-Only、Session Fa?ade模式給Entity Beans注入了活力。當然，并發用戶多、數據流量很大時才會體現出使用Entity Beans的優勢。其中，有一點很關鍵：要注重Entity Beans技術的性能調優，各個應用服務器都有自己的一套性能調優方案。對于JBoss 3.2.1，配置文件standardjboss.xml提供了Entity Beans技術調優的入口。比如，Bean Lock策略的合理使用對于Entity Beans的調優就顯得很重要。這樣使得，我們可以更加關注于系統的商業邏輯，而不只是底層的Database（EJB調優處于EJB Container中，因此我們處在J2EE性能的高端，而不是底端，即Database層。同時，Database層的調優使得J2EE系統的數據庫移植性大打折扣。）。
簡而言之，要結合各個系統的特定需求和狀況給出具體的技術架構方案，而不能孤單的論述技術本身的好壞。
2.Framework的合理選用
設計模式在J2EE應用系統中扮演著重要的角色。因此，有一個問題擺在大家面前，是自己來實現具體的設計模式，還是借助于Third-party Framework。如果貴公司不大，或者說公司不想在J2EE基礎應用Framework投入很多精力，選用現有的較為成熟的、穩定、與現有J2EE Specification兼容的技術框架會比較明智。
一般而言，Framework本身，或者說J2EE平臺本身都是實現并優化了具體的設計模式、規則，比如業務代理、Service Locator（包括Web Tier和EJB Tier各自的服務定位器，起到統一管理有限資源、Cache相關資源的作用，便于系統移植）、Front Controller、DAO等等。現有的J2EE Framework比較豐富。比如：
Struts: 對于實現了Model 2類型的Framework，對于現在以及將來（隨著JSF規范、技術的成熟），選用她是一種明智之舉。目前，Struts已經發展到1.1版本。其內在的MVC主線、對后端數據操作方式沒有限定、集合了Apache Jakarta項目組的優秀相關項目的精華，可謂是開發J2EE應用的佳品。同時，對于具有.NET Web Forms功能的下一代J2EE平臺技術JSF而言，Struts本身可考慮到與JSF的兼容和集成性。比如，通過JSP呈現表示層、Servlet呈現控制層、EJB呈現數據存儲層。各層之間，可以通過值對象、HTTP相關對象來通訊，實現J2EE相關技術的完美應用。
一般情況下，待開發的目標產品不宜采用過多的Framework。其一，J2EE各個技術發展很快，過多的Framework使得系統的后續升級、維護不利；其二，可以借鑒其中的好的一面，比如研究realMethods實現的相應的設計模式，并改造她以適合我們的項目需求；其三，Framework本身會有變動，如果選用過多，會給開發團隊加重負擔，從而不利于項目管理。有選擇的使用現有的成熟Framework能提升大家的開發效率、開發水平。
3，開發模式的選擇
開發J2EE應用要求目標開發人員能夠掌握其中的各種技術。但是，現實情況不是這樣。作為一個團隊，每個人都有自己不同的技能優勢、興趣以及悟性。同時，J2EE本身需要體現社會分工。一般情況下，我們的開發團隊不會有Specification所要求的各個開發角色。現實往往只有3種（也可能是兩種）：美工、JSP程序員、EJB程序員。面對這種分工，團隊更要注重溝通、交流，注重代碼的一致性。
一般情況下，團隊要盡量采用版本控制工具管理代碼、盡量做到每天都有一個完整的運行版本。經過一段時間，團隊都會適應這種開發模式。其中，版本控制工具一定要使用，便于代碼的管理、控制和備份。這其中會牽扯到很多層面。比如，開發工具的選擇要考慮到版本控制工具的使用、建模工具的合理使用有助于團隊有效的溝通和交流。
4，注重各個階段的測試工作
測試是分階段的。單元測試，比如借助于JUnit，來保證功能正確等內容。集成測試，來保證系統沒有內存泄漏等內容。其中，Optimizeite Suite Enterprise對于完成Profiler、Code Coverage、Thread Debugger等內容很有幫助。我記得，我寫的一個Swing桌面應用存在內容泄漏，但是想了很多辦法都沒有解決問題。后來，采用Profiler獲得了答案。因此，現在開發應用，我們很多時候都采用Optimizeite Suite Enterprise作為測試工具。尤其是，在做集成測試過程中，檢查系統的內存泄漏、性能很有幫助。
測試是分類型的。壓力測試、性能測試。就目前對支持J2EE應用的測試而言，并沒有很好的測試工具。但是，一般情況下，借助于Rational Robot也能夠取得不錯的效果。
當然，成功開發J2EE應用的因素有很多。比如，Entity Beans的成功應用很大程度上與底層Database的設計有關系（如果表結構設計設計的不合理，將導致Entity Beans性能的急劇下降）；如何最大化挖掘、提升團隊各個成員的J2EE技能。等等這些，設計面很廣。