《Wrox:J2EE設計開發程式設計指南》的前言

grape88發表於2003-07-19
程式設計
這是《Wrox:J2EE設計開發程式設計指南》的前言，作者的一些話說到了我這個J2EE新兵的心裡，所以在完整的這貼出來了。

筆者相信，J2EE是當今可用於企業軟體開發的最佳平臺。它結合了Java程式語言的各種優點和過去10多年中企業軟體開發的種種教訓。
然而，這一承諾未必完全得到實現。許多J2EE工程專案中的投資回報是令人失望的。傳輸系統的速度常常太慢，結構常常過於複雜。開發時間常常和業務需求的複雜性不成比例。
原因出在什麼地方呢？與其說是由於J2EE中的缺陷所致，倒不如說是因為J2EE常常沒有得到正確使用的緣故所致。而不正確地使用通常是由忽視現實問題的體系結構和開發的方法所引起的。起著主要作用的一個因素是許多J2EE出版物中過分強調各種J2EE規範，而忽略了人們使用這些規範來解決的各種現實問題。現實應用中常常出現的許多問題受到了忽視。
當閱讀J2EE討論論壇時，筆者強烈地感覺到，許多開發人員幾乎沒有找到自己的行動準則和方向，結果浪費了大量時間和精力。在許多情況中，這些開發人員具有多年的IT經歷，但仍覺得掌握J2EE很困難。
問題不是缺少關於J2EE元件的資訊。許多圖書和全球資訊網站點在描述小服務程式、企業Java元件（Enterprise JavaBean，簡稱EJB）等方面都做得非常出色，而且對JNDI、RMI和JMS之類的技術也討論得很充分。
問題出在如何達到下一個水平――怎樣獲得這些構造材料並使用它們以便在一段合理的期限內構造出滿足現實業務需求的應用。在這方面，筆者覺得現有的大部分J2EE作品起著一種阻礙作用，而不是幫助作用。J2EE圖書的世界與企業軟體專案的世界之間存在一道鴻溝，也就是說脫了節。
本書的目標就是解決這個脫節問題，並提供如何在實踐中有效地使用J2EE的明確方向和行動準則。筆者將幫助讀者解決J2EE的常見使用問題，以及避免在J2EE專案中常犯的高代價錯誤。筆者將向讀者揭示各J2EE服務和API的複雜性，以便讀者能夠按時間和預算要求構造出儘可能簡單的可能解決方案。筆者將採用一種注重實際經驗和實際效果的方法，進而對J2EE正統方法在實踐中未能實現正確結果的地方提出質疑，並推薦已得到實踐證明的有效方法。
筆者覺得，沒有任何一本現有圖書實現了這一目標。最接近這一目標的圖書或許是Prentice Hall所出版的“Core J2EE Patterns”一書（ISBN：0-13-064884-1），這本書的出版曾經引起不少人的激動，因為終於有了一本論述如何使用J2EE元件的圖書。“Core J2EE Patterns”確實是一本好書，也是J2EE設計師和開發人員的一個寶貴資源。尤其是，它所使用的方法已經得到廣泛接受，但它是一個Sun出版物，而且無法幫助反映“各方的策略”。
這本書也只關注各種J2EE標準，而極少關注使用真正伺服器時所遇到的問題。它沒有提供明確的行動準則：只是經常不偏不倚地給出各種非常不同的可替換“設計模式（Design Pattern）”，不做任何具體的分析。已經能夠在這些“設計模式”之間自信地做出選擇的讀者從本書中幾乎得不到什麼收穫。
筆者見過的現有出版物、示例應用和討論論壇越多，就越堅信J2EE需要一劑注重實際效果的健康良藥。J2EE是一個偉大的平臺。遺憾的是，針對它而提倡的許多體系結構沒有幫助解決許多常見的問題。許多J2EE示例應用（比如Sun公司的Java Pet Store）十分令人失望。它們沒有面對現實問題。它們的效能非常差，而且它們的程式碼常常沒有考慮現實問題，因而提供了沒有太大價值的模型。
筆者還深深感覺到，J2EE的新手與已經使用J2EE構造企業系統的開發人員之間在見解方面存在著差距。筆者以前的一名同事使用了一個引人遐想的絕妙詞彙“多瘤的”來形容已經掌握了一項技術的實際使用技巧同時又留下了許多疤痕的開發人員。雖然J2EE的新手看起來像是遵守清規戒律的J2EE傳教士，但“多瘤的”開發人員有所不同。他們不得不拋棄一些意識形態上的包袱來實現必要的功能度或達到足夠的效能。像筆者的同事和筆者本人一樣，他們已經發現，現實粗暴地改變了最初的想像。
在本書中，筆者將利用自己的親身經歷和行業知識幫助讀者設計並開發出切實可行的解決方案，同時又不需要讀者經歷一個痛苦的過程來發現J2EE理論與現實之間的差距。
J2EE的神秘性
筆者以為，導致人們對J2EE失望的原因通常可以追溯到幾個常見的神秘之處，而這幾個神秘之處又證實了開發專案中的許多明顯和隱含的假設。
・ J2EE在應用伺服器和資料庫之間具有可移植性。
・ J2EE是所有企業軟體開發問題的最佳答案。如果使用非J2EE技術（比如RDBMS儲存過程）能夠解決的問題也能利用J2EE技術來解決，那麼使用“純”J2EE方法總是最好的。
・ J2EE伺服器負責效能和可縮放性，從而讓開發人員能夠集中精力實現業務邏輯。開發人員可以在很大程度上忽略J2EE“模式”的效能含義，並依賴產品中的可接受效能。
・ J2EE能夠讓開發人員忘了資料存取和多執行緒化之類的低階問題，因為這些問題將由應用伺服器透明地處理。
・ 所有J2EE應用都應該使用企業Java元件（EJB），因為EJB是開發企業級應用的最基本J2EE技術。
・ J2EE方面的任何問題不久將由更先進的J2EE應用伺服器來解決。
下面，讓我們來看一看上述每一個神秘之處。
可移植性是J2EE平臺的一大饋贈。正如我們將要看到的，可移植性可以在實際應用中得以實現，但這不是J2EE的本質所在。絕大部分工程專案的需求是構造這樣一個應用：它很好地解決一個目標平臺上的某一個特定問題。在一個平臺上執行很差的應用將永遠不會被移植到其他平臺（該應用可以被移植到執行在硬體威力更強的計算機上的另一個作業系統來獲得足夠的效能，但這不是專業開發人員所期望的那種可移植性）。
J2EE正統觀念認為，應用在J2EE應用伺服器之間應該是可移植的，並且必須能夠處理不同的資料庫。這兩大目標之間的區別是非常重要的，有時也被忽視。應用伺服器之間的可移植性可以實現商業價值，因此常常也是一個現實的目標。資料庫之間的可移植性比較容易實現，因此常常沒有太大的商業價值。
可移植性通常被誤認為“程式碼可移植性”：獲得應用程式並能夠無修改地在另一個平臺上執行它的能力。筆者以為，這是一個需要付出極高代價的誤解。對總程式碼可移植性的幼稚強調往往會在生產效率損失和不令人滿意的交付方面導致嚴重的後果。儘管“編寫一次，到處執行（WORA）”是Java本身所關注的一個現實目標，但同樣也是一個適合於企業軟體開發的危險口號，視資源的範圍而定。

筆者不是在談論開發“縮小包裝式（shrink-wrapped）”構件（通常指EJB）的少數工程專案。這個頗具吸引力的概念仍需要到市場中得到驗證。而且，筆者還見過一個以這兩者為目標的重要構件：應用伺服器可移植性（在這種情況下有意義）和資料庫可移植性（幾乎肯定會比它所值得的更麻煩）。

筆者更喜歡“設計一次，在任何地方重新實現幾個介面（DORAFIA）”的口號。筆者承認，這句口號不那麼有吸引力，而且讓Java開發人員遵守它也是不可能的。但是，這種比較注重實效的方法在視窗化系統之類的其他領域內得到了廣泛應用。
可移植性的神秘已經導致人們廣泛地認為J2EE不能使用當今關聯式資料庫的能力，而只能使用它們作為轉儲儲存器。這種觀點在現實生活中造成了極壞的影響。
這並不是說，筆者不相信J2EE應用能夠或者應該是可移植的。筆者只是在說明一種更注重實效、更實際的可移植性觀點。我們可以把J2EE應用設計成能夠被輕鬆地移植，我們不能用諸如.NET之類的專有技術做同樣的事情。
想像到J2EE是企業體系結構發展的最後階段是十分令人愉快的；物件技術和Java語言的應用終於解決了10多年來困擾著業界的問題。遺憾的是，這不是現實，儘管在J2EE開發的許多方法中暗示了這一點。J2EE建立在早於它之前出現的許多技術之上。它只是向前進了一步，但不是最後一步，而且沒有解決企業軟體開發的所有問題。
對可移植性的過分強調以及這種以J2EE為中心的態度，已經導致這樣一種假設：如果在標準J2EE中不能做某一件事情，那麼做這件事情將是一個設計錯誤。這種假設甚至正在蔓延到隨著EJB QL的引進而出現的EJB規範中（EJB QL是一種可移植但還不太成熟的查詢語言，並且與可用於絕大多數J2EE應用的熟悉、成熟而又標準的SQL相比顯得更復雜，但威力卻更小）。
筆者把J2EE伺服器看做一組企業資源（比如資料庫）的指揮者。一個好的指揮對任何表演來說都是不可或缺的。但是，指揮不應該試圖演奏各個樂器，而是應該把這項工作留給技巧熟練的專業人員。
最危險的神秘性或許是這樣一種觀點：J2EE是能夠產生好的效能和可縮放性的一條方便的途徑，同時其效率是一個比已得到認可的J2EE“設計模式”更無需擔心的問題。這種觀點會導致幼稚和效率不高的設計。這是非常遺憾的，因為Java業界之外的人對Java一直有這樣一種恐懼心理：Java的效能極差。現在，事實表明Java語言提供了很好的效能，但有些流行的J2EE“設計模式”仍提供非常差的效能。
我們無法假設應用伺服器能夠負責效能和可縮放性。事實上，J2EE給我們提供了捆綁J2EE應用伺服器和資料庫所需要的全部繩索。由於最佳效能一直是軟體開發的主要追求目標，所以我們一直在用C和組合語言編寫Web應用。但是，效能對現實應用的商業價值是至關重要的。我們不能依賴Moore規則來讓我們利用更快的硬體去解決效能問題。無論硬體威力有多麼強大，出現效能問題的可能性始終是存在的。
J2EE伺服器應該透明地處理資料存取之類的低階細節這一想法是非常有吸引力的。有時，這是可達到的，但會十分危險。另外，讓我們來看一看關聯式資料庫的例子。處於領先地位的企業級關聯式資料庫管理系統（RDBMS）Oracle使用了一種完全不同於其他任何RDBMS產品的方式來處理加鎖。使用粗糙還是精細事務意味著其效能在不同資料庫之間有很大的差別。這就是說，“可移植性”會是虛假的，因為相同的程式碼在不同的RDBMS中可能會表現出很大差異。
Oracle和其他領先產品的價格都十分高昂，而且擁有令人印象深刻的能力。我們經常希望（或者需要）直接利用這些能力。J2EE在諸如事務管理和連線共享之類的基礎結構性服務方面提供了十分有價值的標準化，但在任何時候，我們都將不放棄各種厚厚的RDBMS產品說明手冊。
“J2EE = EJB”神秘性會導致代價高昂的錯誤。EJB是一種複雜的技術，雖然很好地解決了一些問題，但在許多情況下也增添了比其商業價值更大的複雜性。筆者覺得，大多數圖書都忽視了EJB的非常現實的缺點，而鼓勵讀者自動使用EJB。在本書中，筆者將冷靜地分析EJB的長處和弱點，並提供關於何時使用EJB的明確準則。
允許所使用的技術（J2EE和其他任何一種技術）來確定一個業務問題的解決方法往往會導致很差的結果。此類錯誤的例子包括決定業務邏輯應該始終用EJB來實現，即決定實體元件是實現資料存取的單一方法。事實上，只有J2EE元件的一個很小子集（筆者認為還應該包括伺服器小程式和無狀態會話EJB），才是大多數J2EE應用的核心。其他J2EE元件的價值在很大程度上取決於待解決的問題。
筆者主張一種問題驅動而非技術驅動的方法（Sun公司的“J2EE Blueprints”透過建議一種J2EE技術驅動的方法，可能已實際造成了不良的影響）。儘管我們應該努力避免重複發明已有的東西，但是盲目地遵從我們絕不應該親自實現伺服器能夠實現（儘管是無效率地實現）的東西這一正統觀念將會付出極高的代價。用來處理事務管理等的核心J2EE基礎結構是一個天賜之物，但這並不是說各種J2EE規範中所描述的所有服務都是天賜之物。
有些人將會爭辯說所有這些問題不久將會得到解決，因為J2EE應用伺服器變得越來越先進。例如，Container-Managed Persistence（容器管理式永續性，簡稱MCP）實體元件（Entity bean）的超高效實現將證明它比使用原始SQL的RDBMS存取具有更快的速度。這是幼稚的，並具有不可接受的風險。在IT行業中，幾乎沒有為信心留有什麼地方。制定決策必須依據已得到證明的確鑿證據，而且信心可能會用錯地方。
現在，人們仍在激烈地爭論著這樣一個問題：J2EE的某些特性（比如實體元件）在許多情況中永遠都無法像某些替代方法那樣管用。而且，“理想中的樂土”仍然很遙遠。例如，實體元件在1999年被首次引進到EJB規範中時，不久就提供了卓越的效能。然而，接下來的兩年暴露了該原始實體元件模型中的嚴重缺陷。現在，EJB 2.0規範中的各種徹底變革仍有待證明，而且EJB 2.1規範已正在設法解決EJB 2.0規範中的遺留問題。
本書的不同之處
首先，本書的觀點是獨立的，以筆者和同事在生產實踐中使用J2EE的經驗為基礎。筆者不打算佈道。筆者主張使用J2EE，但警告讀者謹防J2EE正統方法。
其次，本書的焦點是注重實際經驗。筆者想幫助讀者使用J2EE實現高價效比的應用。本書的目標是揭開J2EE開發的神秘性。它解釋如何使用J2EE技術來減少而不是增加複雜性。儘管筆者並不把焦點集中在任何一個單獨的應用伺服器上，但將討論讀者使用實際產品時可能會遇到的一些問題。本書將不迴避各種J2EE規範沒有自然解決的現實問題。例如，我們在EJB層中怎樣使用Singleton設計模式？在EJB層中應該怎樣做日誌記錄？
本書不打算包括J2EE的全部情況，只打算解釋解決常見問題的有效方法。例如，它將重點介紹如何與關聯式資料庫一起使用J2EE，因為大多數J2EE開發人員都會面對O/R對映問題。一般說來，本書只打算在解決最常見的問題方面提供大量的幫助。
在全書中，我們將只著眼於一個統一的示例應用。在討論每個問題時，我們不是使用一個不切實際的抽象示例，而是著眼於一個規模較大而又較注重實際的完整示例的一小部分。這個示例應用就是一個聯機售票應用。它的設計目的不是為了舉例說明特定的J2EE技術（像許多示例應用那樣），而是為了說明J2EE設計師和開發人員所面對的常見問題。
本書注重的是質量、可維護性和生產效率。
這是筆者在處理自己的第一個J2EE工程專案時希望自己能夠備有的圖書。這樣，它將會節省筆者大量的努力，也將會節省筆者僱主大量的金錢。
筆者採用的方法
本書是面向問題的，而不是面向規範的。和許多論述J2EE的其他圖書不同，本書不打算全面介紹所有的服務和API，而是承認並非J2EE的所有部分都是同樣有用的，或者說對所有開發人員都是有意義的，而且將討論的重點放在構造典型解決方案中所用到的那些部分上。
軟體設計與其說是科學不如說是一門藝術。J2EE的豐富性意味著尋找出同一個問題的多個有效解決方案（和許多壞的解決方案）常常是有可能的。儘管筆者盡了最大努力來解釋自己的觀點（或偏見），但本書自然也反映了筆者使用J2EE的經驗和對待J2EE使用的看法。筆者介紹了自己覺得非常管用的一種方法。但是，這並不意味著它是惟一有效的方法。
本書大體上反映了筆者對待軟體開發的如下看法：
・ 筆者努力避免宗教式的立場。筆者永遠理解不了有那麼多的開發人員花費那麼多的經歷和熱情致力於UseNet上的激烈爭論。這實在沒有什麼好處可言。
・ 筆者是一名實用主義者。筆者關心結果勝於意識形態。當處理一個工程專案時，筆者所追求的主要目標是按時和按預算交付一個高質量的結果。筆者所使用的技術是實現這個目標的一種工具，而不是結果本身。
・ 筆者認為OO原理應該加強J2EE開發。
・ 筆者認為可維護性對任何一個已交付專案的價值是至關重要的。
為了保持與這一實用主義方法相一致，筆者將經常引用Pareto Principle（巴累託定律），該定律說少量的原因（20%）擔負結果的絕大部分（80%）。巴累託定律（最初起源於經濟學）非常適用於實際的軟體工程，而且我們在動手處理J2EE工程專案時將會不斷地遇到它。例如，它可以提醒我們，設法解決某一特定領域中的所有問題會比只解決大多數實際應用中的各種要緊問題困難得多（而且價效比低得多）。

筆者的方法反映了Extreme Programming（極限程式設計，簡稱XP）的一些教訓。筆者是一名方法學懷疑論者，不打算大肆宣傳XP。這不是一本論述XP的圖書，但筆者覺得XP給J2EE理論提供了一個寶貴的補充。尤其是，我們將會看到下列定律的價值：
・ 簡單性。XP專業人員主張做“可能管用的最簡單事情”。
・ 避免浪費精力。XP專業人員不新增他們可能永遠不需要的功能。這種方法用首字母縮寫詞YAGNI（You Aren’t Going to Need It）來表示。
・ 重點放在整個開發過程中的測試上。
讀者物件
本書的閱讀物件是Java設計師、已經使用過J2EE的開發人員以及擁有J2EE基礎知識而又希望從事J2EE專案的Java開發人員。
本書不是EJB、小服務程式、JSP和J2EE的入門讀物。不熟悉這些領域的讀者在閱讀本書時可能需要參考一本綜合性參考書（參見下文的推薦讀物）。
本書目標
本書的目標是讓讀者能夠輕鬆自如地制定J2EE開發的體系結構決策與實現決策。
在閱讀完本書之後，熟悉J2EE的基本概念但可能還沒有任何J2EE使用經驗的開發人員，將能夠自信地嘗試J2EE專案。經驗豐富的設計師或開發人員，將能夠從本書以實用角度為出發點的J2EE體系結構與實現的討論中受益。論述專案選擇、測試和工具的各章節對正試圖瞭解採用J2EE技術有什麼影響的經理們特別有用。
本書內容
本書所涉及的內容包括：
・ 如何做出關鍵性的J2EE體系結構選擇，比如是否使用EJB以及在何處實現業務邏輯。
・ J2EE Web技術，以及Model-View-Controller（模型－檢視－控制器，簡稱MVC）體系結構模式在Web應用中的有效使用。
・ 如何有效地使用EJB 2.0，其中包括引進含有本地介面的EJB所造成的各種影響。
・ 如何選擇應用伺服器。
・ 對J2EE開發至關重要的OO開發原理。
・ 在J2EE應用中使用Java元件（JavaBean），以及這種使用如何幫助開發可維護與可移植的應用。
・ 在J2EE應用中使用XML和XSLT。
・ J2EE事務管理。
・ 如何在J2EE應用中有效地訪問關聯式資料庫。
・ 如何使用通用的基礎結構程式碼來解決常見問題，並保證應用程式碼只關注問題區內的業務邏輯。
・ 如何測試J2EE應用，特別是如何測試Web應用。
・ 如何設計具有滿意效能的J2EE應用，以及如何改善現有應用的效能。
・ 包裝和部署J2EE應用。
・ 主流應用伺服器（比如BEA WebLogic和Oracle 9 Application Server）的特徵，而這些特徵可能會影響我們設計J2EE應用的方式。
・ 瞭解可縮放性的基礎性設計選擇的各種影響。
本書還包括和討論了能夠在讀者的應用中使用的大量通用基礎程式碼。
閱讀本書的前提知識
閱讀本書的前提知識包括：
・ 足夠的Java語言技能；
・ OO原理的牢固掌握；
・ 對經典OO設計模式的熟悉；
・ 對JSP的一定熟悉；
・ 對Web和分散式物件協議（如HTTP和IIOP）的熟悉；
・ 對J2EE的基礎（如RMI、JDBC和JNDI）的瞭解。
再具有下列知識是最理想的：
・ 關聯式資料庫基礎知識；
・ 對事務概念（ACID屬性和隔離層次）的瞭解；
・ 對XML和XSLT的基本瞭解；
・ 對UMI，尤其是對類和序列圖表的基本瞭解；
・ 對基本電腦科學概念（如資料結構）的熟悉。
推薦讀物
本書參考了由Addison Wesley出版的經典圖書“Design Patterns: Elements of Reusable Object-Oriented Software”一書（ISBN 0-201-63361-2）中所討論的23個設計模式。雖然這本經典著作中所介紹的許多模式只不過編纂了任何一名經驗豐富的OO專業人員的設計習慣，但為設計師提供了一種公用語言，並且是任何一名需要提高技能的開發人員的必讀之物。本書假設讀者已經閱讀過並理解了這本經典著作。
本書還使用了由Prentice Hall出版的“Core J2EE Patterns：Best Practices and Design Strategies”一書（ISBN 0-13-064884-1）中所介紹的設計模型名稱，因為這些模式名稱已經得到廣泛的接受。雖然不必參考“Core J2EE Patterns”一書也能閱讀本書，但建議讀者讀一讀這本書。不過需要注意的是，筆者在幾個方面推薦了一種不同的方法。另外，“Core J2EE Patterns”一書的某些章節，特別是和實體元件（Entity bean）有關的那些章節在EJB 2.0規範釋出之後已經過時。
另外，本書的一些J2EE設計模式參考了由Wiley出版的“EJB Design Patterns”一書（ISBN 0-471-20831-0）。同樣，建議讀者讀一讀這本書，儘管它不是必讀的背景讀物。
閱讀一本論述J2EE 1.3平臺的好參考書也是很有必要的。筆者推薦由Wrox Press出版的“Professional Java Server Programming J2EE 1.3 Edition”一書（ISBN 0-471417-11-4中文版《J2EE程式設計指南（1.3版）已由電子工業出版社出版》）。由Ed Roman編寫和Wiley出版的“Mastering Enterprise JavaBeans（Second Edition）”（ISBN 0-471-41711-4）也是一本論述EJB的好書。
讀者可以從http://java.sun.com/j2ee/sdk_1.3/techdocs/api/index.html站點上聯機地獲得針對J2EE 1.3平臺的完整Javadoc。
最後，所有專業的J2EE設計師和開發人員都應該參考定義J2EE 1.3平臺的各種規範，這些規範可以從http://java.sun.com/j2ee/download.html站點上獲得。在本書中，筆者將參考下列規範的相關部分（比如EJB 17.4.1節）：
・ J2EE 1.3
・ EJB 2.0
・ Servlet 2.3
・ JSP 1.2
在相關的地方，筆者還將參考現在仍處於公開草案階段並且也可以從Sun站點上獲得的各種J2EE 1.4規範版本：EJB 2.1、Servlet 2.4和JSP 2.0。
使用本書的軟硬體需求
為了執行本書中的示例，讀者將需要：
・ Java 2 Platform，Standard Edition SDK v1.3或以上版本。我們使用了Sun SDK 1.3.1_02來執行所有樣本程式碼。
・ 一個支援J2EE 1.3的應用伺服器。我們為本書中的示例應用使用了JBoss 3.0.0。
・ 一個RDBMS。我們為示例應用使用了Oracle 8.1.7i。讀者可以從Oracle站點上獲得“Personal Edition”的一個免費評估複製。要想使用一個不同於Oracle 8.1.7或以上版本的資料庫，讀者將需要對示例應用做一些修改（文中已明確標出）。
要想執行示例應用，讀者將需要下列第三方庫：
・ Apache Log4j 1.2
・ JSP Standard Tag Library（JSTL）1.0的一個實現
要想使用第3章中所討論的那些測試策略，讀者將需要如下產品：
・ JUnit 3.7或以上版本
・ Apache Cactus J2EE測試框架
要想執行第13章中的所有Web內容生成示例，讀者將需要如下產品：
・ Apache Velocity 1.3
・ Lutris XMLC 2.1
・ iText PDF生成庫
・ Domify XML生成庫
關於如何安裝和配置最後這4個產品的資訊，請參見附錄A。
上面所討論的所有第三方產品和庫都是免費的，並且是開放原始碼的。
要想構造原始碼，讀者將需要Apache Ant 1.4.1或較新版本，其中包括可選的任務支援。
本書中所有示例的完整原始碼可以從我們的Web站點http://www.wrox.com/上透過下載來得到。下載有兩個版本：一個版本含有上面討論的所有庫，而另一個版本是一個小得多的捆綁，且只含有本書中所討論的原始碼和編譯程式碼。如果讀者已經擁有或者希望下載上面所列舉的那些第三方產品，只需下載那個較小的版本即可。
本書中的約定
為了幫助讀者從正文中獲得最大的資訊量和跟蹤正在發生的事情，我們在整本書中使用了許多約定。

這含有不應該忘記的重要資訊，而且這些資訊與周圍的正文直接相關。

這種背景樣式用於當前討論的旁註。

至於正文中的其他樣式，本書使用瞭如下約定。
・ 當介紹重要單詞時，給出了它們的原文。
・ 使用後面的樣式表示鍵盤上的鍵擊：Ctrl-K。
・ 使用後面的樣式表示正文中的檔名、程式碼以及使用者介面上的文字和URL：persistence.properties。
本書使用兩種方式表示程式碼：

In our code examples, the code foreground style shows new, important, pertinent
Code.
While code background shows code that’s less important in the present context, or
Has been seen before.
客戶支援
我們始終十分重視聽取讀者的反饋意見，而且希望知道讀者對本書的看法：喜歡什麼，不喜歡什麼，希望我們下次在什麼方面做得更好。讀者可以把自己的意見發給我們：給feedback@wrox.com傳送電子郵件。請務必在郵件中註明書名。
如何下載本書的示例程式碼
當訪問Wrox站點http://www.wrox.com/時，透過我們的Search工具，或者透過使用書名列表之一，簡單地找出本書的書名。然後，單擊Code欄中的Download，或者單擊本書的詳細資訊頁上的Download Code。
可以從我們的站點中下載的檔案已經使用WinZip進行過歸檔。當讀者已經把那些附件儲存到自己的硬碟驅動器上的一個資料夾中時，需要使用WinZip之類的解壓縮程式抽取那些檔案。當抽取那些檔案時，程式碼通常被抽取到章資料夾中。當開始抽取過程時，讀者需要確保自己的軟體（如WinZip）被設定成使用資料夾名。
勘誤表
我們已經盡了一切力量保證正文或程式碼中沒有任何錯誤。但是，人無完人，出錯是在所難免的。如果讀者在我們的某本書中發現了錯誤之處，比如拼寫錯誤或故障程式碼，我們將非常感激讀者提供反饋資訊。透過傳送勘誤表，你可以節省其他讀者受挫的時間，當然也可幫助我們提供更高質量的資訊。請直接把這些資訊以電子郵件的形式傳送給support@ wrox.com，你的資訊將接受檢查，如果正確，這些資訊將被張貼到用於本書的勘誤表頁上，或用在本書的後續版本中。
要想查詢Web站點上的勘誤表，請轉到http://www.wrox.com，並透過我們的Advanced Search工具或書名列表，簡單地找出書名。然後，單擊Book Errata連結，該連結在本書的詳細資訊頁上位於封面圖形的下面。
p2p.wrox.com
要想與作者和同行討論，請加入P2P郵件表。除了我們的一對一電子郵件支援系統之外，我們的特有系統還提供關於郵件表、論壇和新聞組的programmer to programmerTM聯絡人。如果張貼一個查詢到P2P上，讀者可以確信你的問題正被許多Wrox作者和當時正在我們的郵件表上的其他業界專家所檢查。不僅在閱讀本書期間，而且在開發自己的應用期間，讀者都將會在p2p.wrox.com上找到許多對自己有幫助的不同列表。
要想訂閱一個郵件表，只需按如下步驟進行操作即可：
1. 轉到http://p2p.wrox.com/。
2. 從左選單欄上選擇合適的類別。
3. 單擊希望加入的郵件表。
4. 按照說明來訂閱和填寫你的電子郵件地址和密碼。
5. 回覆你所接收到的確認電子郵件。
6. 使用訂閱管理器來加入更多的列表，並設定你的電子郵件引數選擇。

本系統為什麼提供最佳支援
讀者可以選擇加入那些郵件表，也可以選擇將它們作為一個周文摘來接收。如果沒有時間或便利工具來接收郵件表，讀者可以搜尋我們的存檔檔案。宣傳和垃圾郵件已被刪除，而且你自己的電子郵件地址將由特有的Lyris系統來保護。關於加入或離開郵件表的查詢以及關於郵件表的其他任何一般性查詢，都應該被髮送給listsupport@wrox.com。

From：
http://www.cnforyou.com/query/bookdetail.asp?viBookCode=9234

相關文章