企業級Java EE架構設計精深實踐 [Practice Of Enterprise J2EE Architecture] pdf epub mobi txt 电子书下载 2025

☆☆☆☆☆

羅果著

下载链接在页面底部

facebook linkedin mastodon messenger pinterest reddit telegram twitter viber vkontakte whatsapp 复制链接

想要找书就要到求知書站

tushu.tinynews.org

立刻按 ctrl+D收藏本页

你会得到大惊喜!!

出版社：清华大学出版社

ISBN：9787302434702

版次：1

商品编码：11944458

包装：平装

外文名称：Practice Of Enterprise J2EE Architecture

开本：16开

出版时间：2016-06-01

用纸：胶版纸

页数：500

字数：758000

正文语种：中文

具体描述

産品特色

編輯推薦

“開源中國”知名博主“悠然”扛鼎大作！作者在開源中國開博兩年，博客瀏覽量近百萬次！

開源中國創始人紅薯先生、特贊CTO黃勇先生、恒生電子CTO範徑武先生傾情作序並推薦！

圖書正式上市前一周作者博客預售，300多讀者已經付款購買！

奉行“好的軟件架構是‘品’齣來的，好的軟件架構一定是簡單的”的原則寫作！

本書是一本怎樣的書？

1. 基於Java EE技術路綫；

2. 麵嚮企業級應用；

3. 以實踐為主，每章解決一個具體問題，每章都提供開發案例；

4. 重點解決企業級架構中的問題及其解決方案；

5.可以保證書中的問題解決方案一定是相當不錯的解。

特色鮮明，上乘之作！

1. 全麵涵蓋緩存、文件處理、模闆語言、服務層、數據庫架構、數據庫水平擴展、元數據、Web架構、前端界麵等企業級應用架構技術；

2. 提供大量的原創實踐及原理性講述，讓讀者對企業級Java EE架構有較為深入的理解；

3. 每章解決一個具體問題，采用“問題背景→需求分析→解決思路→架構設計→實踐示例→章節總結”的順序組織內容；

4. 注重內容的實用性和可操作性，每章都給齣瞭實踐性很強的開發案例。

內容簡介

《企業級Java EE架構設計精深實踐》全麵、深入介紹瞭企業級Java EE設計的相關內容，內容涵蓋瞭Java EE架構設計的常見問題。《企業級Java EE架構設計精深實踐》每一章講解一個Java EE領域的具體問題，采用問題背景、需求分析、解決思路、架構設計、實踐示例和章節總結的順序組織內容，旨在通過分析相關領域中的常用框架及存在問題，給齣相應的解決方案，提高讀者分析和解決問題的能力，並增強其架構設計的能力。

《企業級Java EE架構設計精深實踐》共13章。內容主要包括虛擬文件係統實踐、緩存實踐、文件處理框架實踐、模闆語言實踐、數據庫訪問層實踐、數據庫擴展實踐、服務層實踐、流程引擎實踐、元數據實踐、展現層開發實踐、Web擴展實踐、Tiny統一界麵框架實踐和RESTful實踐。附錄中給齣瞭相關學習資源和配置運行指南。

《企業級Java EE架構設計精深實踐》語言簡潔，思路清晰，示例豐富、完整，適閤具有一定Java基礎的讀者閱讀，尤其適閤從事企業級Java EE軟件架構和設計的人員閱讀。

快速瞭解本書13個技術專題：

虛擬文件係統實踐

緩存實踐

文件處理框架實踐

模闆語言實踐

數據庫訪問層實踐

數據庫擴展實踐

服務層實踐

流程引擎實踐

元數據實踐

展現層開發實踐

Web擴展實踐

Tiny統一界麵框架實踐

RESTful實踐

作者簡介

羅果專注於企業級Java EE開發平颱領域。涉獵廣泛，在模塊化、元數據、模闆引擎、數據庫分區分錶、SOA等領域都有深入實踐。吃過很多虧，上過很多當，但堅信實踐齣真知。業餘時間熱心於開源技術，熱衷於技術分享，撰寫瞭大量的技術博客，從問題、原理和實踐幾個方麵深入淺齣地講述知識。在“開源中國社區”開博兩年，其博客瀏覽量已近百萬次。所開發的Java EE開源框架Tiny，入駐“開源中國社區”兩年以來，獲得的Star和Fork數都已雙雙近韆，是開源中國極具活力的開源項目之一。

內頁插圖

精彩書評

這本書主要是通過對比各種流行的框架和技術來展示Tiny框架強悍又便利的優點。從前端模闆展現、數據庫訪問、緩存，再到文件係統、服務分層、流程引擎、元數據和RESTful，同時還延伸到瞭係統擴展，可以說是麵麵俱到。這本書在介紹Tiny框架的同時對與其對應的一些Java EE開源框架或技術也做瞭簡單的講解，同時包括對同類産品的分析。以悠然如此善於深入分析各類産品的技術來看，可知對這些問題領域的分析及其解決方案便是本書的精華所在，不得不推薦！

——開源中國創始人紅薯

Tiny框架的作者悠然是一位樂於分享的技術專傢，他在“開源中國社區”上分享瞭大量的技術文章。現在Tiny團隊將他們幾年的研究成果成書，並毫無保留地分享給各位技術愛好者。我也非常榮幸地提前看到瞭全書內容，相信本書一定會讓您在架構和設計方麵有所收獲。

——特贊（tezign.com）CTO 黃勇

本書得益於作者的深厚功底及勇敢實踐，並以企業應用中遇到的十多個真實應用場景作為主題進行架構實踐，對這些主題按問題概述、分析問題、解決問題的過程進行瞭有益探索。書中的問題解決方案可以保證是相當不錯的解，應該說都體現瞭作者在這方麵所做的努力。

——恒生電子執行總裁/CTO 範徑武

精彩書摘

第1章虛擬文件係統實踐

VFS（Virtual File System），虛擬文件係統。那麼什麼是現實的文件係統，什麼又是虛擬的文件係統呢？舉個例子，我們的硬盤有C盤、D盤等，其下又有各種文件夾以及文件，那麼我們認為它就是現實的文件係統；而虛擬文件係統呢，它是根據現實的文件係統，在內存中構建的一套虛擬係統，目的是方便我們程序操作現實的文件係統。可以說它（VFS）是我們對現實文件係統的一種抽象。

1.1 背景介紹

一開始我們是沒有做一個VFS的想法的，齣於對Apache的絕對信任，我們選擇瞭Apache VFS 2.0來作為Tiny框架的VFS解決方案。確實，它的API是統一的、優雅的，支持的協議種類也比較多，在簡單評估之後，覺得就用它吧，總不能什麼輪子都自己造。

於是Apache VFS就被依賴到框架，功能也完全良好。但是在壓力測試的時候，卻發現有內存泄露問題，DUMP一下內存，進行分析之後發現原來是Apache VFS 2.0惹的禍，看一看Apache VFS已經好久沒有升級瞭，通過跟蹤源碼，發現有些地方比較詭異，有時候進入有時候不進入，查之良久而不得。想自己修改吧，代碼結構太過復雜，嘗試瞭幾次沒有成功，隻好下決定把Apache VFS從裏麵拿掉，而拿掉之後，就需要實現類似的功能，不得已纔決定自己寫一個VFS。

1.2 什麼是VFS

VFS（Virtual File System）的作用就是按照提供統一文件處理接口來訪問不同來源的不同文件，即為各類文件係統提供瞭一個統一的操作界麵和應用編程接口。VFS是一個可以使文件訪問不用關心底層的存儲方式及來源類型就可以工作的中間層。

一般來說，VFS框架都會設計一個FileObject（或類似）接口。它代錶一個文件對象，和Java的File類不同，它具有更多延伸的功能和信息，可以用來定義任何來源的文件對象。每個FileObject對象代錶一個邏輯文件，能夠被用來訪問邏輯文件的內容和位置等信息。

1.3 VFS對比

Apache VFS是一款比較優秀的開源框架，提供瞭非常全麵的功能支持；而Tiny VFS 則實現瞭幾個主要的功能，同時提供瞭一套自定義擴展方案，接口清晰簡潔。下麵我們從功能點、代碼量等方麵對兩者來做個對比。

1.3.1 Apache VFS

Apache VFS提供瞭一種虛擬文件係統，能夠讓你通過程序很方便地和本地文件、FTP文件及HTTP文件打交道。

從圖1-1可以看齣，真正的Java代碼有21915行，如果包含注釋就是40914行，代碼規模還是非常大的。

圖1 1 代碼行1

1.3.2 Tiny VFS

Tiny的VFS框架，雖然支持的Schema較Apache VFS 稍少，但是主要功能都已實現，用戶也可以根據需要自行擴展其他的模式提供者。

支持的Schema：

? JarSchemaProvider，注冊本地jar模式提供者；

? WsJarSchemaProvider，注冊wsjar協議的模式提供者；

? ZipSchemaProvider，注冊本地zip模式提供者；

? FileSchemaProvider，注冊file協議的模式提供者；

? HttpSchemaProvider，注冊http協議的模式提供者；

? HttpsSchemaProvider，注冊https協議的模式提供者；

? JBossVfsSchemaProvider，注冊vfs虛擬協議的模式提供者；

? FtpSchemaProvider，注冊ftp協議的模式提供者。

從圖1-2可以看齣，Java代碼隻有1523行，包含注釋也不過2505行，代碼結構更清晰、簡潔，可維護性更強。

圖1 2 代碼行2

1.4 VFS框架設計思想

前麵介紹瞭虛擬文件係統（VFS）的基礎定義，以及Apache VFS和Tiny VFS。計算機技術發展的早期階段，還沒有網絡概念，文件存儲隻能在本地。後來隨著局域網和互聯網的齣現，程序員可以通過網絡協議遠程訪問文件；而現在雲存儲的興起，使得文件的操作更加簡單：程序員甚至不用關心文件的真實物理位置，通過虛擬的雲地址就可以完成所有操作。如果針對不同的文件來源就要在程序中編寫相應的處理代碼，勢必會導緻開發成本上升，維護升級睏難，因此虛擬文件係統（VFS）的齣現是計算機技術發展的必然結果。

VFS框架的齣現，有如下幾點優點：

? 統一文件資源的訪問方式，簡化應用資源的開發。程序員不用關心文件是本地文件、FTP遠端文件還是第三方運營商提供的雲存儲文件。

? 屏蔽應用層通信協議和底層文件格式的差異，甚至隱藏不同客戶端的代碼差異。

? 采用接口方式定義VFS，也方便以後對新協議的擴展，符閤軟件開發的開閉原則。

對一個虛擬文件係統而言，最基礎的概念有三點：VFS管理器、SchemaProvider模式提供者和FileObject虛擬文件訪問接口。三者關係如圖1-3所示。

圖1 3 VFS框架設計圖

程序員可以通過VFS管理器獲取指定路徑的FileObject對象，但是實際上VFS自己不做具體的事情，它委托注冊在VFS中的模式提供者做實際的解析，並將解析到的結果，也就是虛擬文件對象返迴給調用者。

VFS管理器類似於總包，模式提供者相當於分包，FileObject對象就是最終結果。總包（VFS管理器）本身不做任何具體工作，它負責管理和對外對接，所有的具體工作都是分配給自己的分包（模式提供者）完成。接到一個任務，它會依次詢問每個模式提供者是不是其職能範圍：如果是，則委派這個分包完成工作任務；不是的話，就問下一個模式提供者；萬一問到最後也沒有模式提供者能完成的話，VFS管理器就會使用默認的模式提供者去完成工作任務。

開發者可以通過擴展並把擴展的新的模式提供者注冊到VFS管理器，然後就可以通過VFS管理器解析特定來源的文件瞭。

1.5 VFS實現講解

這裏列舉瞭幾個重要的接口，來說明VFS的實現原理。

1.5.1 VFS管理器

VFS管理器是作為工具類提供的，因此采用靜態工具類的方式進行展示。核心方法如錶1-1所示。

錶1 1 VFS方法說明

方法名方法說明

addSchemaProvider 增加新的模式提供者

getSchemaProvider 根據模式名稱獲取對應的模式提供者

setDefaultSchemaProvider 設置默認的模式提供者

resolveFile 根據String類型的協議地址解析FileObject

resolveURL 根據URL類型的協議地址解析FileObject

為瞭便於開發人員使用，VFS管理器內置瞭一些模式提供者，以支持常見的文件來源協議，如下：

static {

addSchemaProvider(new JarSchemaProvider());//注冊本地jar模式提供者

addSchemaProvider(new WsJarSchemaProvider());//注冊wsjar協議的模式提供者

addSchemaProvider(new ZipSchemaProvider());//注冊本地zip模式提供者

addSchemaProvider(new FileSchemaProvider());//注冊file協議的模式提供者

addSchemaProvider(new HttpSchemaProvider());//注冊http協議的模式提供者

addSchemaProvider(new HttpsSchemaProvider());//注冊https協議的模式提供者

addSchemaProvider(new FtpSchemaProvider());//注冊ftp協議的模式提供者

addSchemaProvider(new JBossVfsSchemaProvider());

//注冊其他vfs虛擬協議的模式提供者

}

通過addSchemaProvider方法，開發人員可以給VFS管理器增加新的模式提供者，從而擴展對新的URL協議或者格式的處理能力。

VFS管理器解析URL過程如下：

（1）根據資源路徑path從緩存容器fileObjectCacheMap查詢是否存在已經被解析的FileObject對象，如果存在，則進一步判斷該對象是不是包資源和最近的修改時間戳，如果是沒有被修改的包資源（FileObject對象）就直接返迴，否則繼續下一步。

（2）對資源路徑resource進行轉碼。

（3）設置schemaProvider變量為默認的SchemaProvider模式提供者。

（4）遍曆schemaProviderMap容器，判斷模式提供者是否能處理資源路徑resource，如果能處理，則設置schemaProvider變量為當前的模式提供者，並中斷循環。

（5）調用schemaProvider的resolver接口，獲得FileObject對象。

（6）判斷FileObject對象是不是包資源，如果是則放入緩存容器，並記錄修改的時間戳。

（7）返迴解析結果。

resolveFile代碼示例如下：

public static FileObject resolveFile(String resourceResolve) {

String resource=resourceResolve;

//根據協議地址從緩存中查詢FileObject

FileObject fileObject = fileObjectCacheMap.get(resource);

if (fileObject != null && fileObject.isInPackage()) {

//檢查FileObject的最近修改時間戳和緩存中的是否一緻，如果一緻的話就直接返迴結果

long oldTime = fileModifyTimeMap.get(resource);

long newTime = fileObject.getLastModifiedTime();

if (oldTime == newTime) {

return fileObject;

}

//取得默認的模式提供者FileSchemaProvider

SchemaProvider schemaProvider = schemaProviderMap.get(defaultSchema);

for (SchemaProvider provider : schemaProviderMap.values()) {

//遍曆模式提供者，判斷協議地址是否匹配當前模式提供者

if (provider.isMatch(resource)) {

schemaProvider = provider;

break;

}

//返迴解析結果

fileObject = schemaProvider.resolver(resource);

//如果fileObject是包資源，則更新fileObject緩存和時間戳信息

if (fileObject != null && fileObject.isInPackage()) {

fileObjectCacheMap.put(resource, fileObject);

fileModifyTimeMap.put(resource, fileObject.getLastModifiedTime());

}

return fileObject;

}

從解析效率和優化性能的角度齣發，VFS管理器在解析匹配虛擬文件時使用瞭緩存機製：會優先根據路徑從緩存中獲取資源，避免重復解析資源。如果是包資源（如jar 包、zip包），隻要資源沒有被修改，也隻會被解析一次，從而提升整體性能，提升查找速度。

1.5.2 SchemaProvider模式提供者

模式提供者是虛擬文件解析的執行者，由VFS管理器調度。如果需要解析新的模式，隻需要實現對應的SchemaProvider接口，並注冊到VFS管理器即可，接口方法說明如錶1-2所示。

錶1 2 SchemaProvider方法說明

方法名方法說明

getSchema 返迴處理的模式

isMatch 是否匹配。如果返迴true，則錶示此提供者可以處理；返迴false錶示不能處理

resolver 解析資源，並返迴文件對象

前言/序言

序一

我不明白為什麼相比於其他的編程語言，Java的世界充滿瞭各種框架和架構。可能是因為Java太過於靈活，也可能是因為官方對Java EE規範所提供的 API 都是非常底層的東西，很少牽扯到具體的業務需求。雖然這樣可以在一定程度上保證規範本身的兼容性和適應性，但也因此導緻瞭用Java開發一些具體業務應用時顯得過於煩瑣，不夠輕便和快捷。於是齣現瞭Struts等開源框架，再就是後來Javaer們耳熟能詳的SSH三大框架，直至今天琳琅滿目的各種開發框架。所有的這些框架，其唯一的目的就是簡化業務邏輯的開發，其手法無不是利用各種各樣的設計模式對 API 的各種層次進行封裝。

我曾經發文公開反對初學者在對 Java 知之甚少的情況下學習各種框架。主要原因有兩點：一是知其然而不知其所以然；二是更換框架後學習成本很高。因為先入為主的思想作怪，當本書作者（我們姑且就叫他的網名“悠然”吧）第一次將他的Tiny框架提交到“開源中國”的時候，我並沒有過多的關注。哦，僅僅是又一個新的Java EE框架而已。

Tiny 再次進入我的視綫是在“開源中國”社區圍繞該項目越來越多的關注和討論，而且不斷齣現在我們的各種開源項目榜單中。另外，Tiny開源框架不同於其他開源框架的突齣特點是代碼提交非常活躍。可以毫不誇張地說是“開源中國”GIT庫中Commits提交最多的開源者。當然還有另外一個非常重要的原因是悠然寫瞭一篇非常專業的“噴文”，該文章非常專業地指齣我本人的一個開源項目J2Cache中存在的各種設計的不足，專業到讓我無言以對，甚至頗有“挑釁”的意味。如此專業的設計思路及對代碼近乎完美的追求，讓我相信Tiny必然也會是在這種要求下的産物。此外，其團隊利用該框架快速開發的幾個應用類項目，也證明瞭其在開發效率上的提升是非常顯著的。

這本書主要是通過對比各種流行的框架和技術來展示Tiny框架強悍又便利的優點。從前端模闆展現、數據庫訪問、緩存，再到文件係統、服務分層、流程引擎、元數據和RESTful，同時還延伸到瞭係統擴展，可以說是麵麵俱到。基本上你在開發Java EE應用時涉及的絕大多數技術層麵上的內容，本書都會詳盡講述。

前麵我說過反對初學者一開始從框架入手進行學習。這本書在介紹Tiny框架的同時，對與其對應的一些Java EE開源框架或技術也做瞭簡單的講解，同時包括對同類産品的分析。以悠然如此善於深入分析各類産品的技術來看，可知對這些問題領域的分析及其解決方案便是本書的精華所在，不得不推薦！

最後我想提一下：沒有最好的框架，隻有最適閤自己的框架。當你麵對數百個Java框架一臉茫然的時候，考慮一下這麼幾個要素：是否打心眼裏喜歡？是否足夠簡單和輕便，而不是充斥一堆你根本用不上的特性？項目本身在社區上是否足夠活躍？作者本人長得帥不帥（開個玩笑）……如果上麵所有的答案都是否定的，那就自己造一個吧！

開源中國創始人紅薯

序二

十年前，我上大學的時候，就聽說Java這門計算機語言已經很流行瞭。Java分為J2SE、J2EE和J2ME這三大平颱，分彆對應桌麵、Web和移動這三大領域。當時我為瞭找到一份高薪工作，放棄瞭自己所擅長的C++，也學著彆人開始學習Java，尤其是學習當時市場需求量最大的J2EE技術。我學瞭JSP、Servlet和EJB這幾種J2EE核心技術，也學瞭經典的MVC框架Struts和最流行的ORM框架Hibernate。想當年，我可以熟練地使用JSP+Struts+Hibernate開發一個小型Java Web應用程序，輕鬆地應對畢業設計，自己也可以接點私活賺點外快。但對於大型企業級應用而言，首選技術還是EJB。所謂企業級就是一個既安全又復雜的技術，因為它需要考慮到多方麵的問題，所以會帶來一係列的復雜問題。但凡用過EJB的人，都會感受到那是一場痛苦的經曆。而Spring的到來，改變瞭這一切，給企業級J2EE帶來瞭“春天”，Spring+Struts+Hibernate三個框架組閤也被廣泛地應用於Web開發，並且大傢稱其為SSH組閤。

十年後，Java還能位居編程語言排行榜首，我真的慶幸自己當年的選擇是正確的。以前的J2EE，現已改名為Java EE，也許這樣的命名會更加有意義。而以前的SSH，卻顯得有些重量級瞭。也許是因為它們自身的特性越來越多，或者是因為輕量級的框架越來越多，例如我開源的Smart框架，就是一款輕量級的Java Web框架，為瞭講明白該框架的開發過程，我也寫過一本叫做《架構探險》的書（一不小心就為自己做瞭一個廣告，還是言歸正傳吧）。很多大型企業級應用會放棄掉一些技術，例如Struts、Hibernate和JSP等，但Spring目前仍然還是主流，尤其是Spring MVC，足以取代Struts。此外，輕量級JDBC框架MyBatis（以前叫做iBatis）也可以取代Hibernate，所以現在企業級Java EE架構的首選變成瞭Spring+Spring MVC+MyBatis，簡稱SSM。

不管是SSH還是SSM，都隻是開發框架而已，並非技術解決方案。大傢知道，企業級應用是一個相當復雜的應用係統，需要的不僅僅是一個開發框架，更是一係列的技術解決方案。這些解決方案包括虛擬文件係統、緩存、文件處理框架、模闆語言、數據庫訪問層、數據庫水平擴展、服務層、流程引擎、元數據、展現層、Web層、統一界麵框架、RESTful和模塊化等，這些纔是企業級應用的核心需求。Tiny框架將這些需求迎刃而解，代碼完全開源，並且在國內有良好的技術社區網站（tinygroup.org）。更重要的是，Tiny框架的作者是一位樂於分享的技術專傢，在開源中國網站（oschina.net）上分享瞭大量的技術文章。現在Tiny團隊將他們幾年的研究成果匯集成書，並毫無保留地分享給各位技術愛好者。我也非常榮幸地提前看到瞭全書內容，相信本書一定會讓您在架構和設計方麵有所收獲。

使用Tiny，可以讓開發者從復雜的技術細節跳齣來，而將精力集中到業務上，從而節省很多時間。熱愛研究技術的朋友們也可以通過閱讀本書獲取技能上的提升，成為一名優秀的架構師。

祝願Tiny的將來會越來越好！開源改變生活，開源改變世界

特贊（tezign.com）CTO 黃勇

2016年1月31日於上海

序三

最近《三體》非常火，書中說到瞭三體文明將質子做維護展開的情形，甚至展開的質子可以覆蓋整個星球。

其實在軟件應用實踐過程中，也存在多種不同層次的維度。例如，從用戶角度來看，主要是人機交互上的一些感觀；從業務角度來看，主要是各種不同的業務功能；從架構角度來看，軟件又分屬於不同的獨立的體係，這些體係的相互作用最終構成瞭整個軟件；從機器執行過程來看，又都是一些0101的二進製代碼流或數據流……

如果直接使用基礎開發語言和一些基礎類庫來進行開發，當軟件比較小的時候沒有任何問題。但是作為一個企業級應用來說，如果還是采用同樣的模式，那麼後果將會是不堪設想的。我見過許多業務上非常成功，但是由於沒有良好的架構支撐而已經崩潰或走嚮崩潰的係統。真正優秀和成功的軟件産品，必須有一個良好的架構支撐，纔可以實現持續的發展和進步。

本書得益於作者的深厚功底及勇敢實踐，並以企業應用中遇到的十多個真實應用場景作為主題進行架構實踐，對這些主題按問題概述、分析問題和解決問題的過程進行瞭有益探索。雖然不能說所有的解決方案一定都是最優的，但是應該說都體現瞭作者在這方麵所做的努力。“一花獨放不是春，萬紫韆紅春滿園。”，也歡迎有更多、更好的企業級架構方麵的實踐書籍湧現齣來，促進企業級Java EE應用的發展。

恒生電子股份有限公司執行總裁/CTO 範徑武

2016年1月25日於杭州

前言

從本書的書名《企業級Java EE架構設計精深實踐》可以看到幾個關鍵詞：企業級、Java EE、架構和實踐。簡單地說，本書是一本基於Java EE技術路綫，麵嚮企業級應用，解決企業級應用架構問題，並以實踐為主的書籍。

目前市場上已經有瞭許多Java EE領域的書籍，涵蓋瞭Java EE規範、Java EE的各種流行前後颱框架等。這些書籍有一些寫得非常好，比較全麵地覆蓋瞭企業級Java EE應用的方方麵麵。因此本書不會講解Java相關的基礎知識，不會講解Java EE規範方麵的知識，也不會花大量篇幅介紹流行框架的使用及技巧，而是把重點放在需要解決的一些企業級應用中的問題及其解決方案和實踐過程，讓讀者跟隨筆者的思路一起實踐。筆者不能保證書中所有的實踐都是最優解，但一定是相當不錯的解。

企業級應用是本書內容的核心，那麼什麼是企業級應用呢？這個問題本身就沒有標準答案。但是企業級應用涉及的一些領域還是可以列舉的。

? 數據持久化：這裏的數據泛指結構化和非結構化數據。這些數據從産生到消亡有著漫長的創建、更新、查詢和刪除的生命周期，有的數據甚至要存在許多年。這些數據需要為避免丟失而進行存儲操作，為高效利用而進行緩存加載操作，再加上數據自身的CRUD等操作，在上述過程中就需要解決各種各樣的問題。

? 海量並發訪問：對於小的應用係統，訪問者可能就是一個或幾個人，稍大點的係統訪問者有上百人。但是對於企業級應用尤其是互聯網級應用來說，其注冊用戶、在綫用戶和並發請求都是巨大的。應用請求數較少和應用請求數巨大的架構模式是有巨大差異的，由此也會引入許多的架構問題。

? 海量數據：對於企業級應用來說，百萬級數據隻不過是起步，韆萬甚至數十億條數據都是常見的。在數據規模比較小的時候不存在問題，而在數據規模比較大的時候就會齣現嚴重的性能問題。為瞭保證在海量應用的情景下也可以使用，這時原有的數據架構就需要進行重構。

? 應用規模龐大：應用的規模越大，開發、測試、集成和維護起來就越睏難。筆者就親眼見到過一個項目，業務方麵是非常齣色的，但是隨著産品的規模越來越大，而項目的開發方式無法適應，導緻整個項目無法繼續進行，以失敗而告終。所以如何讓應用隨著規模的變大，其開發、測試、集成和維護成本隻是齣現等比例增長，而不是隨著應用規模的變大産生指數級增長，這就變得非常重要瞭。

? 界麵需求復雜：隨著應用規模的變大，企業級應用的界麵也越來越多。而在企業級應用中，又需要對使用權限、界麵一緻性和界麵的易集成性等有非常高的要求。所以在企業級應用中，界麵層有一個良好解決方案是非常有挑戰性的。

? 與第三方係統協作：與小的應用不同，企業級應用的生成周期比較長，一個企業當中又有多個不同方麵的係統同時存在，這些係統之間往往需要有數據或服務協作。但是由於不同的應用可能是來自於不同廠商采用不同開發語言和不同數據庫開發的，所以這就對它們協同運作産生瞭許多問題。

總之，企業級應用可以理解成業務復雜、規模巨大、數據種類多、數據量大、訪問請求大、生命周期長和並發請求巨大的應用。正是由於上述特點而産生瞭許許多多的問題，而這些問題的解決方案往往是有衝突的，因此如何藝術性地解決這些問題就往往需要從架構上想辦法。

本書重點介紹的Tiny框架是Tiny開源小組曆經5年業餘時間，孜孜不倦地投入與堅持的産物。它是通過團隊艱苦卓絕的努力所構建的體係完整、內容龐大的企業級開源框架。筆者和Tiny團隊在解決這些問題時做瞭大量的嘗試和實踐，在諸多領域都有非常專業的解決方案，我們非常願意通過本書與讀者分享。

本書特色

1．基於原創，開拓思路

本書有大量的原創實踐及原理性講述，不管讀者用不用本書中的框架，都可以對企業級Java EE架構中的一些技術及其解決方案有較為深入的理解，這對於讀者開拓思路，避免踩同樣的“坑”有非常強的藉鑒作用。

2．涵蓋廣泛，講解深入

本書介紹的內容都是當前主流框架和優秀技術，涵蓋緩存、文件處理、模闆語言、服務層、數據庫架構、數據庫水平擴展、元數據、Web架構和前端界麵等Java EE領域經常用到的知識，涉及企業級應用架構開發的方方麵麵。對這些內容的講解不是泛泛而談，而是有相當的深度。

3．內容實用，注重實踐

本書內容非常注重知識的實用性和可操作性，這些內容都是作者多年以來構建Java EE開發框架實踐過程中的寶貴經驗匯集而成的。本書每章都給齣瞭實踐性很強的開發案例供讀者理解。

4．思路清晰，文筆簡練

本書每章按照問題背景、需求分析、解決思路、架構設計、實踐示例和章節總結的順序行文，絲絲入扣，符閤人們的認知規律。而且本書行文風格樸實，文筆簡練，知識的講解由淺入深、循序漸進，即便是初學者，隻要肯用心也會有所收獲。

5．與眾不同，切中要害

本書有相當多的實踐具有“反模式”的特質，也就是說與常見的解法不一樣，再輔之以簡單的示例，可以讓讀者非常容易理解其設計精要，有醍醐灌頂之感覺。

6．理論與實踐齊抓，局部與整體並重

本書注重問題的解決思路和開發細節，既介紹瞭企業級Java EE架構的設計思想，也兼顧瞭應用的具體實踐，避免瞭學習過程中理論與實踐的脫節，連貫而統一。本書每章都有獨立的測試用例，最後還提供瞭完整的Web開發案例，這樣通過先局部後整體的方式，可以讓讀者更好地理解Java EE開發架構。

7．編排科學，適用麵廣

本書內容編排既可以讓初學者對Java EE架構有整體的認知，也可以讓那些學有餘力、經驗豐富的開發人員深入鑽研自己感興趣的內容。無論是哪個層次的讀者，閱讀完本書後都會有所收獲，甚至對以前自己覺得深不可測的問題有豁然開朗的感覺。

本書內容

本書正文共13章，采用問題背景、需求分析、解決思路、架構設計、實踐示例和章節總結的順序來組織內容。下麵簡單介紹一下每章的內容。

第1章虛擬文件係統實踐

本章從Apache VFS框架存在的內存泄露Bug說起，引入企業級應用常見的虛擬文件係統的概念，並介紹瞭Apache VFS框架和Tiny VFS框架。另外，還講解瞭VFS的設計思想，介紹瞭VFS管理器、虛擬文件接口和模式提供者等概念，並給齣本地文件、JAR和FTP的實踐用例。

第2章緩存實踐

本章以Java EE應用遇到的性能問題作為話題，引導讀者瞭解緩存技術的重要性。在講解一個實際項目緩存的代碼變遷過程中，自然而然地列舉瞭對現有緩存方案的改進：業務代碼與緩存框架分離；具體緩存實現的切換不影響業務開發；支持XML配置等。本章介紹瞭兩種緩存架構：字節碼緩存方案和動態代理緩存方案，並對比瞭兩者的優缺點。希望讀者通過閱讀本章內容，能夠對開發企業級應用有新的心得體會。

第3章文件處理框架實踐

本章介紹瞭文件處理框架，可以有效地解決Java EE應用模塊化導緻的各種配置文件分散在不同模塊而帶來的處理這些資源難度大的問題。在介紹Tiny文件處理框架的過程中，請仔細閱讀文件掃描器接口、文件掃描器主入口和定時掃描器的介紹，理解框架如何把文件的掃描、文件的變化、文件的遍曆等與文件的實際處理分離，體會“開-閉”原則的具體運用。

第4章模闆語言實踐

本章介紹瞭模闆語言及其在Java EE領域的實踐開發。為瞭便於讀者理解，筆者先介紹模闆語言的概念、原理和應用場景，並列舉瞭常見的模闆語言Velocity、FreeMarker和Tiny，比較瞭三者的優勢和不足。特彆是在設計開發的章節，按模闆語言的架構、語法解析和渲染機製的順序，從零開始講解如何構建一種模闆語言。通過對本章內容的學習，有能力的讀者完全可以嘗試擴展模闆語言。

第5章數據庫訪問層實踐

本章首先介紹瞭應用框架的三層架構，然後引入瞭數據庫訪問層的相關概念。為瞭便於讀者理解數據庫訪問層，筆者講解瞭業界常用的數據庫訪問層框架Hibernate、Ibatis和JPA，以及DSL風格的數據庫訪問層JEQUEL、JOOQ和Querydsl。通過比較它們的優缺點，分析瞭Tiny團隊開發TinyDsl的原因，然後詳細說明TinyDsl的實踐過程。最後通過具體示例說明各種數據庫訪問層框架的用法和配置。

第6章數據庫擴展實踐

本章側重介紹數據庫水平擴展方案。首先從互聯網的發展所導緻的業務應用壓力日益增加，從而讓讀者認識到數據庫水平擴展方案對Java EE企業級應用是非常閤理的需求。論證瞭水平擴展的閤理性之後，列舉瞭常見的擴展層次：DAO層、DataSource層、JDBC層和Proxy層，重點講解瞭Tiny分庫分錶的技術架構和設計思路，並講解瞭分庫分錶、讀寫分離和集群事務的處理，還與開源軟件Routing4DB做瞭詳細對比。最後通過具體示例演示數據庫水平擴展的配置和增刪改查的結果。

第7章服務層實踐

本章首先介紹瞭傳統的服務層定義，以及與錶現層、業務邏輯層的關係，然後講解瞭Tiny對服務層的改進，通過重新定義服務概念，引入服務定義、服務注冊和服務中心的設計思路。基於Tiny服務體係，應用可以不必關心服務提供方的具體信息。同時，由於遠程調用與本地調用在代碼層麵並沒有區彆，所以係統根據不同場景進行多機部署或者單機部署時，無須對代碼進行調整。遠程調用體係由核心服務中心來組織整個調用網絡，水平擴展極為容易。最後列舉瞭本地場景、遠程場景、單中心場景和多中心場景下，讀者如何配置部署服務與服務中心。

第8章流程引擎實踐

本章介紹瞭麵嚮對象編程的不足，引入瞭麵嚮組件編程的概念。流程引擎框架（後文亦稱之為Flow）是一款基於麵嚮組件開發的組件流程執行框架。目前Flow支持兩種流程：邏輯流程和頁麵流程。在設計部分，讀者可以通過組件設計、流程管理、流程配置和流程執行瞭解流程引擎的強大。在實踐部分筆者介紹瞭如何通過組件化開發算術錶達式的流程。

第9章元數據實踐

本章介紹的是基本的元數據元素，包含方言模闆、標準數據類型、業務數據類型和標準字段這幾類基礎元數據。最後的示例演示使用Eclipse插件設計元數據，包括通過工具動態生成業務Java代碼和SQL語句。

第10章展現層開發實踐

本章首先介紹瞭Java EE展現層的常用代錶技術Servlet、JSP和模闆語言，並詳細分析瞭三者的特性及優缺點。接著講解瞭展現層方案設計，列舉瞭設計人員常見的做法和技巧。然後給齣瞭Tiny框架的展現層架構思路：采用模闆語言做前端展示，同時引入組件包的概念，通過資源閤並和壓縮等框架手段，提升展現層的性能。最後演示瞭Tiny展現層的告警框和文本輸入框的示例。

第11章 Web擴展實踐

本章主要講解瞭Tiny Web層框架的實踐過程。首先介紹瞭Tiny Web層框架的由來及設計思想與設計原理。然後詳細介紹瞭框架內置過濾器與處理器的使用方式。最後通過具體示例講解Tiny Web層框架的開發過程，從而加強對Tiny Web層框架的理解。

……

編著