初學者如何開發出一個高質量的J2EE系統

J2EE學習者越來越多，J2EE本身技術不斷在發展，涌現出各種概念，本文章試圖從一種容易理解的角度對這些概念向初學者進行解釋，以便掌握學習J2EE學習方向。

　　首先我們需要知道Java和J2EE是兩個不同概念，Java不只是指一種語言，已經代表與微軟不同的另外一個巨大陣營，所以Java有時是指一種軟件系統的流派，當然目前主要是.NET和Java兩大主流體系。

　　J2EE可以說指Java在數據庫信息系統上實現，數據庫信息系統從早期的dBase、到Delphi/VB等C/S結構，發展到B/S（Browser瀏覽器/Server服務器）結構，而J2EE主要是指B/S結構的實現。

　　J2EE又是一種框架和標準，框架類似API、庫的概念，但是要超出它們。如果需要詳細瞭解框架，可先從設計模式開始學習。

　　J2EE是一個虛的大的概念，J2EE標準主要有三種子技術標準：WEB技術、EJB技術和JMS，談到J2EE應該說最終要落實到這三個子概念上。

　　這三種技術的每個技術在應用時都涉及兩個部分：容器部分和應用部分，Web容器也是指Jsp/Servlet容器，你如果要開發一個Web應用，無論是編譯或運行，都必須要有Jsp/Servlet庫或API支持（除了JDK/J2SE以外）。

　　Web技術中除了Jsp/Servlet技術外，還需要JavaBeans或Java Class實現一些功能或者包裝攜帶數據，所以Web技術最初裸體簡稱爲Jsp/Servlet+JavaBeans系統。

　　談到JavaBeans技術，就涉及到組件構件技術（component），這是Java的核心基礎部分，很多軟件設計概念（設計模式）都是通過JavaBeans實現的。

　　JavaBeans不屬於J2EE概念範疇中，如果一個JavaBeans對象被Web技術（也就是Jsp/Servlet）調用，那麼JavaBeans就運行在J2EE的Web容器中；如果它被EJB調用，它就運行在EJB容器中。

　　EJB（企業JavaBeans）是普通JavaBeans的一種提升和規範，因爲企業信息系統開發中需要一個可伸縮的性能和事務、安全機制，這樣能保證企業系統平滑發展，而不是發展到一種規模重新更換一套軟件系統。

　　至此，JavaBeans組件發展到EJB後，並不是說以前的那種JavaBeans形式就消失了，這就自然形成了兩種JavaBeans技術：EJB和POJO，POJO完全不同於EJB概念，指的是普通JavaBeans，而且這個JavaBeans不依附某種框架，或者乾脆可以說：這個JavaBeans是你爲這個應用程序單獨開發創建的。

　　J2EE應用系統開發工具有很多：如JBuilder、Eclipse等，這些IDE首先是Java開發工具，也就是說，它們首要基本功能是可以開發出JavaBeans或Java class，但是如果要開發出J2EE系統，就要落實到要麼是Web技術或EJB技術，那麼就有可能要一些專門模塊功能(如eclipse需要lomboz插件)，最重要的是，因爲J2EE系統區分爲容器和應用兩個部分，所以，在任何開發工具中開發J2EE都需要指定J2EE容器。

　　J2EE容器分爲WEB容器和EJB容器，Tomcat/Resin是Web容器；JBoss是EJB容器+Web容器等，其中Web容器直接使用Tomcat實現的。所以你開發的Web應用程序可以在上面兩種容器運行，而你開發的Web+EJB應用則只可以在JBoss服務器上運行，商業產品Websphere/Weblogic等和JBoss屬於同一種性質。

　　J2EE容器也稱爲J2EE服務器，大部分時它們概念是一致的。

　　如果你的J2EE應用系統的數據庫連接是通過JNDI獲得，也就是說是從容器中獲得，那麼你的J2EE應用系統基本與數據庫無關，如果你在你的J2EE應用系統耦合了數據庫JDBC驅動的配置，那麼你的J2EE應用系統就有數據庫概念色彩，作爲一個成熟需要推廣的J2EE應用系統，不推薦和具體數據庫耦合，當然這其中如何保證J2EE應用系統運行性能又是體現你的設計水平了。

　　衡量J2EE應用系統設計開發水平高低的標準就是：解耦性；你的應用系統各個功能是否能夠徹底脫離？是否不相互依賴，也只有這樣，才能體現可維護性、可拓展性的軟件設計目標。

　　爲了達到這個目的，誕生各種框架概念，J2EE框架標準將一個系統劃分爲WEB和EJB主要部分，當然我們有時不是以這個具體技術區分，而是從設計上抽象爲表現層、服務層和持久層，這三個層次從一個高度將J2EE分離開來，實現解耦目的。

　　因此，我們實際編程中，也要將自己的功能向這三個層次上靠，做到大方向清楚，涇渭分明，但是沒有技術上約束限制要做到這點是很不容易的，因此我們還是必須藉助J2EE具體技術來實現，這時，你可以使用EJB規範實現服務層和持久層，Web技術實現表現層；

　　EJB爲什麼能將服務層從Jsp/Servlet手中分離出來，因爲它對JavaBeans編碼有強制的約束，現在有一種對JavaBeans弱約束，使用Ioc模式實現的（當然EJB 3.0也採取這種方式），在Ioc模式誕生前，一般都是通過工廠模式來對JavaBeans約束，形成一個服務層，這也是是Jive這樣開源論壇設計原理之一。

　　由此，將服務層從表現層中分離出來目前有兩種可選架構選擇：管理普通JavaBeans（POJO）框架(如Spring、JdonFramework)以及管理EJB的EJB框架，因爲EJB不只是框架，還是標準，而標準可以擴展發展，所以，這兩種區別將來是可能模糊，被納入同一個標準了。　但是，個人認爲：標準制定是爲某個目的服務的，總要犧牲一些換取另外一些，所以，這兩種架構會長時間並存。

　　這兩種架構分歧也曾經誕生一個新名詞：完全POJO的系統也稱爲輕量級系統(lightweight)，其實這個名詞本身就沒有一個嚴格定義，更多是一個吸引人的招牌，輕量是指容易學習容易使用嗎？按照這個定義，其實輕量Spring等系統並不容易學習；而且EJB 3.0（依然叫EJB）以後的系統是否可稱爲輕量級了呢？

　　前面談了服務層框架，使用服務層框架可以將JavaBeans從Jsp/Servlet中分離出來，而使用表現層框架則可以將Jsp中剩餘的JavaBeans完全分離，這部分JavaBeans主要負責顯示相關，一般是通過標籤庫（taglib）實現，不同框架有不同自己的標籤庫，Struts是應用比較廣泛的一種表現層框架。

　　這樣，表現層和服務層的分離是通過兩種框架達到目的，剩餘的就是持久層框架了，通過持久層的框架將數據庫存儲從服務層中分離出來是其目的，持久層框架有兩種方向：直接自己編寫JDBC等SQL語句（如iBatis）；使用O/R Mapping技術實現的Hibernate和JDO技術；當然還有EJB中的實體Bean技術。

　　持久層框架目前呈現百花齊放，各有優缺點的現狀，所以正如表現層框架一樣，目前沒有一個框架被指定爲標準框架，當然，表現層框架現在又出來了一個JSF，它代表的頁面組件概念是一個新的發展方向，但是複雜的實現讓人有些忘而卻步。

　　在所有這些J2EE技術中，雖然SUN公司發揮了很大的作用，不過總體來說：網絡上有這樣一個評價：SUN的理論天下無敵；SUN的產品用起來撞牆；對於初學者，特別是那些試圖通過或已經通過SUN認證的初學者，趕快擺脫SUN的陰影，立即開溜，使用開源領域的產品來實現自己的應用系統。

　　最後，你的J2EE應用系統如果採取上面提到的表現層、服務層和持久層的框架實現，基本你也可以在無需深刻掌握設計模式的情況下開發出一個高質量的應用系統了。

　　還要注意的是: 開發出一個高質量的J2EE系統還需要正確的業務需求理解，那麼域建模提供了一種比較切實可行的正確理解業務需求的方法，相關詳細知識可從UML角度結合理解。

　　當然，如果你想設計自己的行業框架，那麼第一步從設計模式開始吧，因爲設計模式提供你一個實現JavaBeans或類之間解耦參考實現方法，當你學會了系統基本單元JavaBean或類之間解耦時，那麼系統模塊之間的解耦你就可能掌握，進而你就可以實現行業框架的提煉了，這又是另外一個發展方向了。

　　以上理念可以總結爲一句話：Java學習開發三件寶: Domain Model（域建模）、Patterns（模式）和Framework（框架）。集三寶理念於一身，小中型J2EE項目快速開發工具：Jdon Framework
----------------------------------------------------------------------------------------------------

JoannaYe ask:
你好 Banq先生 關注你的文章很長一段時間了, 對你在Java領域的技術水平,以及在很多問題上的看法, 也非常佩服. 國內目前達到你的水平的人真是很少(當然高人也許都隱居起來了). 但是, 有幾個問題想與你討論:
首先,軟件是一個絕對的應用技術,任何技術離開了具體的應用, 坦率地說是毫無價值的.我看,Jdon也有在這方面的嘗試,如網站,網上商店生成系統等.但這與真正的企業應用還有非常大的距離. 我不瞭解,你在這一領域裏爲什麼沒有涉足,是因爲你認爲很困難,基本上是以我們國內目前的技術水平無法到達呢, 還是因爲你不屑於這方面的深入, 認爲你所追求的是純粹超然的技術概念呢.
我的其他問題有賴於瞭解你關於這個問題的回答,讓我們繼續關注和討論.

banq answer:
 
>但這與真正的企業應用還有非常大的距離. 我不瞭解,你在這一領域裏爲什麼沒有涉足,是因爲你認爲很困難,基本上是以我們國內目前的技術

多謝探討，這個問題很複雜，大概有下列幾點：
1. 現在軟件技術不再象以前的技術，以前的技術可以說只有做個這個行業大型軟件系統的經驗的人纔可以說對這些軟件技術有掌握，而現在的技術則不必了，J2EE講究架構，J2EE它是一套應用軟件的規範，也就是說，J2EE是很多做過大型軟件的人進行彙總後的經驗精華，一個大型系統需要哪些技術部分、什麼時候適合什麼技術，在J2EE標準中基本都有涉及，例如EJB技術、JMS等。

這樣，如果你能完全掌握和駕馭這些J2EE架構技術，你有時確實不必一定要做個大型軟件經驗才型，這稱爲站在巨人的肩膀上。

但是反過來，如果你沒有豐富的軟件系統實戰經驗，你去理解EJB/JMS等就很困難，所以這兩個技術對初學者比較難的原因之一。

2. UML結合J2EE這樣OO一套實施過程從方法論以及模式角度固化了軟件數據庫系統的分析 設計開發，這也是因爲有MDA（將這些過程用軟件自動生成代碼）誕生的原因。雖然這些簡化了我們開發系統的過程，但是這只是解決了應用系統的一部分問題，工作流等尚未成熟，使用這樣方式開發系統，依據我的經驗，最後會將煩瑣和細緻的工作壓在Jsp頁面上，目前開發一個系統，結合標籤庫和用戶界面需求這個工作反而花費我更多時間，希望JSF在這方面能有效率提升，等這些技術細節都能解決，基本J2EE非常成熟了。

3.目前我通過諮詢角色和一些軟件公司一起承接一些企業應用項目，例如去年承接一個大型外資人事系統，他們要求管理GE 等幾家外資企業的人事福利（這些企業外包人事給他們），如果專爲一家公司開發人事很簡單，但是要求這個人事適合多家，那麼重用性要求很高，設計抽象面很高，他們在新加坡有類似系統，但技術很老，我聽過新加坡的系統，他們也有一些經驗總結，大部分和我的J2EE設計相吻合，我和新加坡的人交流過想法，他們很驚奇，不太相信，加上費用問題，只進行了初步架構設計就擱淺了。

4.不要小看網站系統，以前網站系統都是用PHP Perl做，功能很弱，無法和企業系統相比，但是隨着Inernet普及，更多人要求聯網，例如如果一家公司的ERP通過互聯網實現，那麼老總出差就很方便，但是現在爲一家公司開發一個基於internet的ERP很貴，比傳統的貴，這不合理，這也是SOA提出的目的之一，以後ERP實現網上租用，就象你申請一個Blog或論壇或Email，你可以爲你的企業申請一個ERP系統，這樣只要企業付租費就可以了，這可理想目前已經接近，前段時間美國一家提供這種服務的企業來上海做宣傳，他們的業績增長速度極其快 500%.

通過網站提供ERP等企業服務對於軟件設計的重用性要求很高，就一套郵箱系統可以服務很多用戶一樣，你必須設計出一套重要性、靈活性很高的ERP系統適合不同的用戶，可見網站軟件的水平是極其高的。前面我做的網站自動生成系統到現在我都認爲完成不夠好，現在很多網站都提供這種服務，這象Blog，但是Blog等只限制你網站模板，而不是自由定製頁面，所以Blog這些都是小孩玩家家，根本無發走向商業，著名的那個方興東鼓吹Blog，其實沒有技術革新，靠你媒體吹呼就是革命了。
 
JoannaYe ask:

謝謝 Banq 先生在6月23日非常認真的回覆(抱歉由於忙,沒能馬上回復). 總結起來, 如果我的理解不錯的話, 你的結論是 1)你認爲網站系統並不可小覷(同意,一個高訪問量,同時能夠實現網上交易的網站的確如此).2)EJB/JMS技術對於初學者來說是不容易,但是對你來說,你是可以Handdle的. 3)你也有承接企業系統的實際經驗,象你說的那個HR系統. 但不知您以諮詢身份參加的這個HR系統到底都解決的是實際管理中的什麼樣的問題?在性能方面都達到了什麼樣的水平? 具體來說,採用了哪些技術(諸如您帖中提到的一些技術)應對了實際中具體的什麼樣的問題. 此外以你在這個HR系統的經驗來看, 是一個多少人的Team,採取什麼樣的開發方式和開發進度(人員和時間的分配比例)開發的.你認爲在這樣的一個項目的開發過程中最關鍵的是什麼?最影響 Prductivity的又是什麼?

對這樣一些問題看上去似乎很空泛,但是實際上能夠真正反映出我一開始提出的issue,"軟件是一個絕對的應用技術,任何技術離開了具體的應用, 坦率地說是毫無價值的".舉個例子來說,書本上,名家們會告訴你, Value List Handler 這個設計模式是解決這樣的問題:"You have a remote client that wants to iterate over a large results list." 一般來說,如果是一個大量地查找某一些"topic/dimension"下的數據,這樣的問題,我們也毫無疑問地確定要用到這個模式.但是,如果對一條具體的數據,如某一個銷售員,要和他的客戶討論(在線談判)他們之間的一個具體合同,這時候會不會也需要用到這個模式.如果要用這個模式,到底是用Stateful Session Bean 還是用 Stateless Session Bean 實現呢,他們各自在實現方法上對性能的影響是什麼, 當你決定採用了某種實現方法,你到底是怎樣Tradeoff的呢; 最後對這個設計模式來說,在最終的設計方案中如何把它抽象到對一個通用的,普遍的業務問題,而不是僅僅對"某一個銷售員,要和他的客戶討論他們之間的一個具體合同"這樣的一個特例問題,作出一個通用的解決方案,適應任意規模,任意業務的企業,真正達到軟件工程的目標:高度的Reusing 和 Scalablity. 實際的企業應用系統就是充滿着類似這樣的問題,很有挑戰.但有些技術人員就僅僅滿足於自己可以用某項技術做出一些小的Demo了,就不願意,或根本不屑於深入下去面對一個實際的應用問題.

因此, 我相信您應該能夠非常理解,我爲什麼感興趣瞭解您對我上面提出問題答案.

您的很多看法都很不錯, 我非常同意, 希望我們能在今後進一步深入地探討. 謝謝!

banq answer:

>你認爲在這樣的一個項目的開發過程中最關鍵的是什麼?最影響 Prductivity的又是什麼?

當這樣的項目使用框架組件組合後，由於系統重要 重用的功能已經封裝在框架軟件中，所以，只要能夠組裝出應用系統，一般第一次測試就會立即通過，我已經不止一次體會這種快感，我現在基本告別以前那種花費大量時間在Java調試上時代，我相信很多初學者還在這個泥潭裏掙扎，這就成爲影響一個產品的主要原因，現在使用jdon框架開發，幾乎消滅這個因素。

那麼,現在最影響 Prductivity的是什麼？就是技術外的因素：項目管理。

關於你提的性能方面設計達到什麼水平等，這些我已經整合進入Jdon框架，使用Jdon框架開發，幾乎無需考慮性能設計，一開始就具有優越的性能，這些都是有測試數據，Java產品的好處就是一切可以自己動手，不必聽從第三方評價，因爲那些都有失公正，服務器配置上Jprofile/Optimizeit，客戶端配置Jmeter，啓動幾個線程一跑，Jdon框架和應用程序的性能真相就出來了，所以，在Java領域，開源和商業產品是在同一起跑線，面對不同的用戶：前者是更有頭腦，自己動手；後者是對自己缺乏自信的人；服務是兩者的重點。

>在最終的設計方案中如何把它抽象到對一個通用的,普遍的業務問題,而不>是僅僅對"某一個銷售員,要和他的客戶討論他們之間的一個具體合同"這>樣的一個特例問題

其實你說的行業框架提煉的問題，這和業務相關，Jdon框架等都是基礎框架，沒有這些組件框架的優雅解決方式，就沒有行業框架的好的開始，我想你不希望在行業框架提煉之後，發現無法加入一些縱向功能，就象數據庫設計好之後，幾年以後卻成爲你發展的障礙。

行業框架需要資深的行業背景，這也不是一般人做的，但是工作流/Portal等都是行業框架的提煉，這些也是我們以後發展的方向。

就我個人來說，我願意解決重要問題，然後我告訴更多人解決方向，如果他們相信，大家一起努力來解決所有問題，而不是靠我一個人解決所有問題。

JoannaYe ask:

謝謝Banq先生的回覆, 你的很多觀點都很好,我非常同意.象你所說最影響Prductivity的是技術外的因素：項目管理. 但我不知你能不能有一些具體的看法.因爲任何行業,最終的問題, 競爭力的問題都是如何通過管理來提高Prductivity. 不知你對軟件這一行業有沒有特別的見解.

開源項目的確有它的優勢,特別是作這些開源項目的人,往往是一些技術的精英.但是, 我還是以爲應該以成熟的Commercial產品作爲自己開發的基礎,即所謂"巨人的肩膀". 這是因爲, 成功的Commercial產品往往更注重最終用戶, 這是這些產品能夠給它的公司帶來巨大的商業利潤的源泉.純技術的專家往往會忽視這一點.

要成就一件事(一個大型企業管理應用的項目), 是需要很多人踏踏實實,堅持不懈(這也非常重要)的努力.這和去上上課,或者在場外指導一下,有很大的區別.

我希望通過你這個論壇, 結識一些志同道合的朋友, 能夠作成這樣一件事.再次謝謝你的回覆, 我因爲很多時候很忙,有一些Deadline非常緊的事情,有時沒能馬上給您回覆, 請你見諒.

banq answer:

非常感謝JoannaYe 討論，從言論中感覺你是一個職業的項目經理。非常專業。

項目經理和設計師良好溝通和理解交流，是一個項目成功的關鍵。

關於開源和Commercial區別，我個人覺得它們之間真的沒有嚴格的區別，只不過是兩種思路的表現：開源通過免費產品賣服務；Commercial是既想賣產品又賣服務，不能因爲它的產品賣錢，就是技術好，一般是市場品牌好。

就拿EJB實現來說，在所有J2EE服務器中只有開源JBoss 4.0使用AOP實現，堅持AOP的一些純設計派認爲EJB過時了，那麼Weblogic /Websphere等這些以支持EJB自詡的服務器產品反而不如開源產品呢。這些人認爲：EJB
但是正如你說：爲什麼客戶還是購買Websphere等服務器，因爲它們注重最終用戶。

我認爲一直試圖在這兩者之間尋找平衡是挑戰的事情。

-------------------------------------------------------------------------------------------------------------------
 
shuiwx ask:
 
banq老師好，最近大致抽象總結出了一個比較淺顯的規律，既是您平均一兩個月能夠發一篇比較的適合初學者的帖子，但每一篇都可以對偶的有關知識的梳理和導向能夠起到很重要的作用，不敢說終生受用但也似乎會持久難忘了，在此還是要道一聲感謝。

既然題目是初學者...高質量的J2EE系統，那麼就題目本身這個用例來說，參與者該是“novice”了，領域模型應該是"高質量的"+"J2EE系統",那麼能否請您再深一步的舉個樣例來說明何爲"high quality j2ee system"呢？估計您不會選petshop,但有可能會將jive和jdon算進來，但偶真正想看到的是一個就您個人來講曾經有過consultant經驗的項目作爲例子來簡要闡述下高質量+j2ee系統的概貌，或者象您前面某篇論oo和數據庫的矛盾的文章一樣，能否前瞻性的給出一個在您心目中最理想的高質量j2ee系統的輪廓呢？比如jsf(new version>1.1)+ejb3.0+j2ee設計模式?偶覺得struts+spring+hibernate並不敢稱爲高質量的或是j2ee系統，所以總覺得從現在開始既該有意識的用一下jsf+ejb3來設計了，但由於不知道有沒有人在這方面開始吃螃蟹了，所以只好去隨大流的關心些什麼ajax,xp之類的流行名詞了。但從內心來講，無論是javascript還是組件式編程，無論是spring+hibernate還是ejb3,無論是xp還是fdd,無非是想盡量按照客戶的要求迅速提交一個界面新穎，結構穩定的一個能夠跨平臺的良好的系統吧。假如能預知何爲一個好的系統的話，似乎事情會變的簡單些，也就不必爲那些喋喋不休的爭論着技術名詞的人們所困擾了。

但由於目前偶的能力所限和所處的時期的特殊性，似乎想馬上就拿jsf+ejb3來首選做企業級開發還有點不現實，那麼作爲一個apprentice來說，能夠做的似乎只有學習模式了，偶不知道關於模式該學到多深才合適，只相信儘量選擇從建模的時候就配合着設計模式來考慮可能會有助於系統的穩定和重用，談到這裏有引申出關於題目的另外一個話題，就是“初學者”，偶覺得如果想作爲計算機編程人員的話，面對着不停的新技術名詞和版本更迭，似乎偶總要做一名初學着來的說，於是最近有意識的在看一些數據結構方面的課程，希望能夠從一些理論基礎中來尋找那些所謂的新技術背後所蘊涵的知識，但還是那句話，由於能力有限，所得甚淺，所以希望您如果能站在一個諮詢家的角度來看，能否指點一下，就您認爲的如果想設計一個好的軟件系統來說，或許不僅限於j2ee,該多看看哪些computer science中的理論知識呢？偶不知道這個問題提的對不對，但總覺得設計模式對於系統的意義，是類似於數據結構和算法之相對於程序的意義的，所以假如您在類似的方面能有些心得的話，希望能夠得到一點指點。

（偶的廢話似乎不少，希望banq老師能忍受）
 
banq answer:

很抱歉現在纔回復你的問題：
>如果想設計一個好的軟件系統來說，或許不僅限於j2ee,該多看看哪些>computer science中的理論知識

設計一個好的軟件系統我文章裏其實寫了，掌握分層解耦宗旨，學習使用一些現成的框架就可以了，如果你不原意囫圇吞棗，那麼研究一下這些框架設計原理和模式，這些會花費你很長探索，數據結構、編譯原理這些已經成爲底層機制，就象彙編是底層一樣，現在的大學計算機教學完全是錯誤的，學習的都是正確的廢話。所以沒有必要在那些大學課程上浪費時間。

增強項目經驗，研讀源碼，自己動手編寫項目是提升水平的唯一道路。
以上只是我個人意見。