《企業(yè)應用架構模式》作者是當今面向對象軟件開發(fā)的權威，他在一組專家級合作者的幫助下，將40多種經(jīng)常出現(xiàn)的解決方案轉化成模式，最終寫成這本能夠應用于任何一種企業(yè)應用平臺的、關于解決方案的、不可或缺的手冊�！镀髽I(yè)應用架構模式》獲得了2003年度美國軟件開發(fā)雜志圖書類的生產效率獎和讀者選擇獎�！镀髽I(yè)應用架構模式》分為兩大部分。第一部分是關于如何開發(fā)企業(yè)應用的簡單介紹。第二部分是《企業(yè)應用架構模式》的主體，是關于模式的詳細參考手冊，每個模式都給出使用方法和實現(xiàn)信息，并配以詳細的Java代碼或C#代碼示例。此外，整《企業(yè)應用架構模式》中還用了大量UML圖來進一步闡明有關概念。
《企業(yè)應用架構模式》是為致力于設計和構建企業(yè)應用的軟件架構師、設計人員和編程人員而寫的，同時也可作為高等院校計算機專業(yè)及軟件學院相關課程的參考教材。
企業(yè)應用開發(fā)的實踐得益于多種新技術的出現(xiàn)，多層的面向對象平臺（如Java、.NET）已經(jīng)日漸平常。這些新工具和新技術有能力構建更強大的企業(yè)應用程序，但是在實現(xiàn)上還不太容易。由于開發(fā)人員未能充分理解有經(jīng)驗的對象程序開發(fā)人員在架構方面的經(jīng)驗和教訓.因此企業(yè)應用中經(jīng)常存在一些共同的錯誤�！ 镀髽I(yè)應用架構模式》就是面向企業(yè)應用開發(fā)者的，可幫助他們迎接這種艱難挑戰(zhàn)。《企業(yè)應用架構模式》的作者Ma riin Fowler注意到，盡管技術本身存在變化——從Smalltalk到CORBA，再到。Java和NET，但基本的設計思想并沒有太多變化.可以加以適當調整，用來解決那些共同的問題。在一組專家級合作者的幫助下，作者將40多種經(jīng)常出現(xiàn)的解決方案轉化成模式，最終寫成這本能夠應用于任何一種企業(yè)應用平臺的、關于解決方案的、不可或缺的手冊�！镀髽I(yè)應用架構模式》曾于2002年榮獲美國軟件開發(fā)雜志圖書類的生產效率獎和讀者選擇獎�！ 镀髽I(yè)應用架構模式》涉及兩部分內容。第一部分是關于如何開發(fā)企業(yè)應用的簡單介紹。在閱讀這部分時.讀者可以從頭到尾通讀，以掌握《企業(yè)應用架構模式》的范圍。第二部分是《企業(yè)應用架構模式》的主體，是關于模式的詳細參考手冊.每個模式都給出使用方法和實現(xiàn)信息，并配有詳細的Java代碼或C#代碼的示例。此外，整《企業(yè)應用架構模式》中還用了大量UML圖來進一步闡明有關概念�！ 镀髽I(yè)應用架構模式》主要內容： 將企業(yè)應用分層 組織企業(yè)業(yè)務邏輯的主要方法 在對象和關系數(shù)據(jù)庫之間進行映射的深層次解決方案 通過模型一視圖一控制器來組織Web表現(xiàn) 處理跨多事務的數(shù)據(jù)的并發(fā)問題 設計分布式對象接口
“每一個模式描述了一個在我們周圍不斷重復發(fā)生的問題，以及該問題的解決方案的核心。這樣，你就能一次又一次地使用該方案而不必做重復勞動�！�
—Christopher Alexander
本書是面向對象大師Martin Fowler繼《Analysis Patterns》、《UML Distilled》、《Planning Extreme Programming》、《Refactoring》之后的又一力作。
“溫故而知新”。Fowler在本書中再次向我們證明了《禮記》中這句古訓的震撼力—他在回頭審視自己及同仁多年來從事企業(yè)應用開發(fā)的經(jīng)驗和教訓后，歸納總結了40多種企業(yè)應用架構的設計模式。這些模式從不同層次、不同側面向我們展示了什么是好的企業(yè)應用架構？如何設計好的企業(yè)應用？
正如作者自己所言，企業(yè)應用在某些方面比其他軟件（如電信通信軟件）復雜得多：紛繁復雜的企業(yè)數(shù)據(jù)、“不合邏輯”的業(yè)務規(guī)則、變化莫測的用戶需求，等等。環(huán)顧四周—CORBA、J2EE、.NET—企業(yè)應用開發(fā)技術可謂“前仆后繼、層出不窮”，開發(fā)平臺的種類之多就更不必說。
招式套路可以千變萬化，扎實深厚的“內功”卻是始終如一！雖然企業(yè)應用涉及的軟件技術不斷翻新，但是基本的架構及設計思想?yún)s沒有太多變化。將以前行之有效的設計思路和方法加以適當調整，并應用到當前的問題上，是最高效的做法。在一組專家級合作者的幫助下，Martin將40多種經(jīng)常出現(xiàn)的解決方案轉化成模式，最終融會成這本“內功心法”。在仔細研讀、用心揣摩本書之后，希望它能夠幫助你應對任何一種企業(yè)應用平臺，駕馭任何一種企業(yè)應用技術—無論是現(xiàn)在的技術還是未來的技術。
熟悉Fowler的讀者都知道，這位大師的寫作風格可謂是“深入淺出，娓娓道來”。本書也是一樣。前8章是關于企業(yè)應用的背景知識，如分層架構、Web表現(xiàn)、業(yè)務邏輯、數(shù)據(jù)庫映射、并發(fā)、會話、分布策略，等等。在此基礎上，隨后的各章分別對與這些背景知識相關的設計模式進行了詳細的介紹。與其他設計模式的書一樣，本書從模式的使用場景、解決方案、UML表示等方面予以介紹，詳略有致。就連示例的編程語言的選取—Java和C#—也是與他的寫作風格一脈相承的。
夜已深，窗外依舊是綿綿不斷的早春小雨。讓我們酌一杯清茶，一起來品味大師的話，一起來品味“源于實踐、指導實踐”的苦澀與甘甜—
“模式的關鍵點是它們源于實踐。必須觀察人們的工作過程，發(fā)現(xiàn)其中好的設計，并找出‘這些解決方案的核心’。這不是一個簡單的過程，但是一旦發(fā)現(xiàn)了某個模式，它將是非常有價值的。對于我來說，價值之一是能夠撰寫這樣一本參考書。你不必通讀本書的全部內容，也不必通讀任何一本有關模式的書。只需要了解到這些模式都是干什么的、它們解決什么問題、它們是如何解決問題的，就足夠了。這樣，一旦你碰到類似問題，就可以從書中找出相應的模式。那時，你再深入了解相應的模式也為時不晚。”
福勒（Martin Fower），是一位獨立咨詢顧問，他運用對象技術解決企業(yè)問題已經(jīng)超過十年。他的顧問領域包括健康管理、金融貿易，以及法人財務。他的客戶包括Chrysler，Citibank，UK National Health Service，AndersenConsulting，NetscapeCommunications。此外Fowler也是objects、UML、patterns技術的一位合格講師，他是《AnalysisPatterns》和《UML Distilled》的作者。
譯者序
前言
模式列表
引言 1
0.1 架構 1
0.2 企業(yè)應用 2
0.3 企業(yè)應用的種類 3
0.4 關于性能的考慮 4
0.5 模式 6
0.5.1 模式的結構 7
0.5.2 模式的局限性 9
第一部分 表述
第1章 分層 12
1.1 企業(yè)應用中層次的演化 13
1.2 三個基本層次 14
1.3 為各層選擇運行環(huán)境 15
第2章 組織領域邏輯 19
2.1 抉擇 22
2.2 服務層 23
第3章 映射到關系數(shù)據(jù)庫 25
.3.1 架構模式 25
3.2 行為問題 28
3.3 讀取數(shù)據(jù) 29
3.4 結構映射模式 30
3.4.1 關系的映射 30
3.4.2 繼承 33
3.5 建立映射 34
3.6 使用元數(shù)據(jù) 35
3.7 數(shù)據(jù)庫連接 36
3.8 其他問題 38
3.9 進一步閱讀 38
第4章 Web表現(xiàn)層 39
4.1 視圖模式 41
4.2 輸入控制器模式 43
4.3 進一步閱讀 43
第5章 并發(fā) 45
5.1 并發(fā)問題 45
5.2 執(zhí)行語境 46
5.3 隔離與不變性 47
5.4 樂觀并發(fā)控制和悲觀并發(fā)控制 48
5.4.1 避免不一致讀 49
5.4.2 死鎖 49
5.5 事務 50
5.5.1 ACID 51
5.5.2 事務資源 51
5.5.3 減少事務隔離以提高靈活性 52
5.5.4 業(yè)務事務和系統(tǒng)事務 53
5.6 離線并發(fā)控制的模式 54
5.7 應用服務器并發(fā) 55
5.8 進一步閱讀 56
第6章 會話狀態(tài) 57
6.1 無狀態(tài)的價值 57
6.2 會話狀態(tài) 58
6.3 存儲會話狀態(tài)的方法 59
第7章 分布策略 61
7.1 分布對象的誘惑 61
7.2 遠程接口和本地接口 62
7.3 必須使用分布的情況 63
7.4 關于分布邊界 64
7.5 分布接口 64
第8章 通盤考慮 67
8.1 從領域層開始 67
8.2 深入到數(shù)據(jù)源層 68
8.2.1 事務腳本的數(shù)據(jù)源 68
8.2.2 表模塊的數(shù)據(jù)源 69
8.2.3 領域模型的數(shù)據(jù)源 69
8.3 表現(xiàn)層 69
8.4 一些關于具體技術的建議 70
8.4.1 Java和J2EE 70
8.4.2 .NET 71
8.4.3 存儲過程 71
8.4.4 Web Services 72
8.5 其他分層方式 72
第二部分 模 式
第9章 領域邏輯模式 76
9.1 事務腳本（Transaction Script） 76
9.1.1 運行機制 76
9.1.2 使用時機 77
9.1.3 收入確認問題 78
9.1.4 例：收入確認（Java） 78
9.2 領域模型（Domain Model） 81
9.2.1 運行機制 81
9.2.2 使用時機 83
9.2.3 進一步閱讀 83
9.2.4 例：收入確認（Java） 84
9.3 表模塊（Table Module） 87
9.3.1 運行機制 88
9.3.2 使用時機 90
9.3.3 例：基于表模塊的收入確認（C#） 90
9.4 服務層（Service Layer） 93
9.4.1 運行機制 94
9.4.2 使用時機 96
9.4.3 進一步閱讀 96
9.4.4 例：收入確認（Java） 96
第10章 數(shù)據(jù)源架構模式 101
10.1 表數(shù)據(jù)入口（Table Data Gateway） 101
10.1.1 運行機制 101
10.1.2 使用時機 102
10.1.3 進一步閱讀 102
10.1.4 例：人員入口（C#） 103
10.1.5 例：使用ADO.NET數(shù)據(jù)集（C#） 104
10.2 行數(shù)據(jù)入口（Row Data Gateway） 106
10.2.1 運行機制 107
10.2.2 使用時機 108
10.2.3 例：人員記錄（Java） 108
10.2.4 例：領域對象的數(shù)據(jù)保持器（Java） 111
10.3 活動記錄（Active Record） 112
10.3.1 運行機制 112
10.3.2 使用時機 113
10.3.3 例：一個簡單的Person類（Java） 113
10.4 數(shù)據(jù)映射器（Data Mapper） 115
10.4.1 運行機制 116
10.4.2 使用時機 119
10.4.3 例：一個簡單的數(shù)據(jù)映射器（Java） 119
10.4.4 例：分離查找方法（Java） 123
10.4.5 例：創(chuàng)建一個空對象（Java） 126
第11章 對象－關系行為模式 129
11.1 工作單元（Unit of Work） 129
11.1.1 運行機制 129
11.1.2 使用時機 133
11.1.3 例：使用對象注冊的工作單元（Java） 134
11.2 標識映射（Identity Map） 137
11.2.1 運行機制 137
11.2.2 使用時機 139
11.2.3 例：標識映射中的方法（Java） 139
11.3 延遲加載（Lazy Load） 140
11.3.1 運作機制 140
11.3.2 使用時機 142
11.3.3 例：延遲初始化（Java） 142
11.3.4 例：虛代理（Java） 142
11.3.5 例：使用值保持器（Java） 144
11.3.6 例：使用重影（C#） 144
第12章 對象－關系結構模式 151
12.1 標識域（Identity Field） 151
12.1.1 工作機制 151
12.1.2 使用時機 154
12.1.3 進一步閱讀 154
12.1.4 例：整型鍵（C#） 154
12.1.5 例：使用鍵表（Java） 155
12.1.6 例：使用組合鍵（Java） 157
12.2 外鍵映射（Foreign Key Mapping） 166
12.2.1 運行機制 167
12.2.2 使用時機 169
12.2.3 例：單值引用（Java） 169
12.2.4 例：多表查詢（Java） 172
12.2.5 例：引用集合（C#） 173
12.3 關聯(lián)表映射（Association Table Mapping） 175
12.3.1 運行機制 176
12.3.2 使用時機 176
12.3.3 例：雇員和技能（C#） 177
12.3.4 例：使用直接的SQL（Java） 179
12.3.5 例：用一次查詢查多個雇員（Java） 182
12.4 依賴映射（Dependent Mapping） 186
12.4.1 運行機制 186
12.4.2 使用時機 187
12.4.3 例：唱片和曲目（Java） 188
12.5 嵌入值（Embedded Value） 190
12.5.1 運行機制 190
12.5.2 使用時機 190
12.5.3 進一步閱讀 191
12.5.4 例：簡單值對象（Java） 191
12.6 序列化LOB（Serialized LOB） 192
12.6.1 運行機制 193
12.6.2 使用時機 194
12.6.3 例：在XML中序列化一個部門層級（Java） 194
12.7 單表繼承（Single Table Inheritance） 196
12.7.1 運行機制 197
12.7.2 使用時機 197
12.7.3 例：運動員的單表（C#） 198
12.7.4 從數(shù)據(jù)庫中加載對象 199
12.8 類表繼承（Class Table Inheritance） 202
12.8.1 運行機制 202
12.8.2 使用時機 203
12.8.3 進一步閱讀 203
12.8.4 例：運動員和他們的家屬（C#） 203
12.9 具體表繼承（Concrete Table Inheritance） 208
12.9.1 運行機制 209
12.9.2 使用時機 210
12.9.3 例：具體運動員（C#） 210
12.10 繼承映射器（Inheritance Mappers） 214
12.10.1 運行機制 215
12.10.2 使用時機 216
第13章 對象－關系元數(shù)據(jù)映射模式 217
13.1 元數(shù)據(jù)映射（Metadata Mapping） 217
13.1.1 運行機制 217
13.1.2 使用時機 218
13.1.3 例：使用元數(shù)據(jù)和反射（Java） 219
13.2 查詢對象（Query Object） 224
13.2.1 運行機制 225
13.2.2 使用時機 225
13.2.3 進一步閱讀 226
13.2.4 例：簡單的查詢對象（Java） 226
13.3 資源庫（Repository） 228
13.3.1 運行機制 229
13.3.2 使用時機 230
13.3.3 進一步閱讀 231
13.3.4 例：查找一個人所在的部門（Java） 231
13.3.5 例：資源庫交換策略（Java） 231
第14章 Web表現(xiàn)模式 233
14.1 模型－視圖－控制器（Model View Controller） 233
14.1.1 運行機制 233
14.1.2 使用時機 234
14.2 頁面控制器（Page Controller） 235
14.2.1 運行機制 235
14.2.2 使用時機 236
14.2.3 例：Servlet控制器和JSP視圖的簡單演示（Java） 236
14.2.4 例：使用JSP充當處理程序（Java） 238
14.2.5 例：代碼隱藏的頁面控制器（C#） 241
14.3 前端控制器（Front Controller） 243
14.3.1 運行機制 244
14.3.2 使用時機 245
14.3.3 進一步閱讀 246
14.3.4 例：簡單的顯示（Java） 246
14.4 模板視圖（Template View） 248
14.4.1 運行機制 249
14.4.2 使用時機 251
14.4.3 例：分離的控制器，使用JSP充當視圖（Java） 252
14.4.4 例：ASP.NET服務器頁面（C#） 253
14.5 轉換視圖（Transform View） 256
14.5.1 運行機制 256
14.5.2 使用時機 257
14.5.3 例：簡單的轉換（Java） 257
14.6 兩步視圖（Two Step View） 259
14.6.1 運行機制 259
14.6.2 使用時機 260
14.6.3 例：兩階XSLT（XSLT） 264
14.6.4 例：JSP和定制標記（Java） 266
14.7 應用控制器（Application Controller） 269
14.7.1 運行機制 270
14.7.2 使用時機 271
14.7.3 進一步閱讀 271
14.7.4 例：狀態(tài)模型應用控制器（Java） 271
第15章 分布模式 275
15.1 遠程外觀（Remote Facade） 275
15.1.1 運行機制 276
15.1.2 使用時機 278
15.1.3 例：使用Java語言的會話bean來作為遠程外觀（Java） 278
15.1.4 例：Web Service（C#） 281
15.2 數(shù)據(jù)傳輸對象（Data Transfer Object） 285
15.2.1 運行機制 285
15.2.2 使用時機 288
15.2.3 進一步閱讀 289
15.2.4 例：傳輸唱片信息（Java） 289
15.2.5 例：使用XML實現(xiàn)序列化（Java） 293
第16章 離線并發(fā)模式 295
16.1 樂觀離線鎖（Optimistic Offline Lock） 295
16.1.1 運行機制 296
16.1.2 使用時機 298
16.1.3 例：領域層與數(shù)據(jù)映射器（Java） 298
16.2 悲觀離線鎖（Pessimistic Offline Lock） 302
16.2.1 運行機制 303
16.2.2 使用時機 305
16.2.3 例：簡單鎖管理對象（Java） 305
16.3 粗粒度鎖（Coarse-Grained Lock） 310
16.3.1 運行機制 310
16.3.2 使用時機 312
16.3.3 例：共享的樂觀離線鎖（Java） 312
16.3.4 例：共享的悲觀離線鎖（Java） 316
16.3.5 例：根對象樂觀離線鎖（Java） 317
16.4 隱含鎖（Implicit Lock） 318
16.4.1 運行機制 318
16.4.2 使用時機 319
16.4.3 例：隱含的悲觀離線鎖（Java） 319
第17章 會話狀態(tài)模式 321
17.1 客戶會話狀態(tài)（Client Session State） 321
17.1.1 運行機制 321
17.1.2 使用時機 322
17.2 服務器會話狀態(tài)（Server Session State） 322
17.2.1 運行機制 322
17.2.2 使用時機 324
17.3 數(shù)據(jù)庫會話狀態(tài)（Database Session State） 324
17.3.1 運行機制 324
17.3.2 使用時機 325
第18章 基本模式 327
18.1 入口（Gateway） 327
18.1.1 運行機制 327
18.1.2 使用時機 328
18.1.3 例：私有消息服務的入口（Java） 329
18.2 映射器（Mapper） 331
18.2.1 運行機制 332
18.2.2 使用時機 332
18.3 層超類型（Layer Supertype） 332
18.3.1 運行機制 332
18.3.2 使用時機 333
18.3.3 例：領域對象（Java） 333
18.4 分離接口（Separated Interface） 333
18.4.1 運行機制 334
18.4.2 使用時機 335
18.5 注冊表（Registry） 335
18.5.1 運行機制 336
18.5.2 使用時機 337
18.5.3 例：單子注冊表（Java） 337
18.5.4 例：線程安全的注冊表（Java） 338
18.6 值對象（Value Object） 339
18.6.1 運行機制 339
18.6.2 使用時機 340
18.7 貨幣（Money） 340
18.7.1 運行機制 341
18.7.2 使用時機 342
18.7.3 例：貨幣類（Java） 343
18.8 特殊情況（Special Case） 346
18.8.1 運行機制 347
18.8.2 使用時機 347
18.8.3 進一步閱讀 347
18.8.4 例：一個簡單的空對象（C#） 347
18.9 插件（Plugin） 348
18.9.1 運行機制 349
18.9.2 使用時機 350
18.9.3 例：ID生成器（Java） 350
18.10 服務樁（Service Stub） 352
18.10.1 運行機制 352
18.10.2 使用時機 353
18.10.3 例：銷售稅服務（Java） 353
18.11 記錄集（Record Set） 355
18.11.1 運行機制 355
18.11.2 使用時機 356
參考文獻 359
我雖然沒有從事過早期批處理系統(tǒng)時期的任何工作，但我認為當時的軟件工作人員不會太關注層次的概念，只要編寫操作某些文件（ISAM、VSAM等）格式的程序，這就是當時的應用。它不需要層次。
20世紀90年代，隨著客戶／服務器系統(tǒng)的出現(xiàn)，分層的概念更明顯了。這樣的系統(tǒng)是一種兩個層次的系統(tǒng)：客戶端包括用戶界面和其他應用代碼，服務器端通常是關系型數(shù)據(jù)庫。常見的客戶端工具如VB、PowerBuilder和Delphi。這些工具使得構建數(shù)據(jù)密集型應用非常容易。因為它們的用戶界面控件通常都是SQL感知的。因此，可以通過將控件拖拽到“設計區(qū)域”來建立界面，然后再使用屬性表單把控件連接到后臺數(shù)據(jù)庫。
如果應用僅僅包括關系數(shù)據(jù)的簡單顯示和修改，那么這種客戶／服務器系統(tǒng)的工作方式非常合適。問題來自領域邏輯：如業(yè)務規(guī)則、驗證、計算等。通常，人們會把它們寫在客戶端，但是這樣很笨拙，并且往往把領域邏輯直接嵌入到用戶界面。隨著領域邏輯的不斷復雜化，這些代碼將越來越難以使用。而且，這樣做很容易產生冗余代碼，這意味著簡單的變化都會導致要在很多界面中尋找相似代碼。
另外一種辦法是把這些領域邏輯放到數(shù)據(jù)庫端，作為存儲過程。但是，存儲過程只提供有限的結構化機制，這將再次導致笨拙的代碼。而且，很多人喜歡關系型數(shù)據(jù)庫的原因之一是SQL是一個標準，允許他們更換數(shù)據(jù)庫廠商。盡管真正更換數(shù)據(jù)庫廠商的用戶寥寥無幾，但還是有很多人希望擁有這種選擇，并且沒有太大的附加代價。由于存儲過程都是數(shù)據(jù)庫廠商私有的，因此普通用戶被剝奪了這種選擇權。
在客戶／服務器方式逐漸大眾化的同時，面向對象方式開始崛起。面向對象為領域邏輯的問題找到了答案：轉到三層架構的系統(tǒng)。在這種方式下，在表現(xiàn)層實現(xiàn)用戶界面，在領域層實現(xiàn)領域邏輯，在數(shù)據(jù)源層存取數(shù)據(jù)。這種方式使你可以將復雜的領域邏輯從界面代碼中抽取出來，單獨放到中間層，用對象加以建模和組織。
書單推薦
