内容简介

　　《企业应用架构模式》作者是当今面向对象软件开发的专业，他在一组专家级合作者的帮助下，将40多种经常出现的解决方案转化成模式，终写成这本能够应用于任何一种企业应用平台的、关于解决方案的、不可或缺的手册。《企业应用架构模式》获得了2003年度美国软件开发杂志图书类的生产效率奖和读者选择奖。《企业应用架构模式》分为两大部分。一部分是关于如何开发企业应用的简单介绍。第二部分是《企业应用架构模式》的主体，是关于模式的详细参考手册，每个模式都给出使用方法和实现信息，并配以详细的Java代码或C#代码示例。此外，整《企业应用架构模式》中还用了大量UML图来进一步阐明有关概念。
　　《企业应用架构模式》是为致力于设计和构建企业应用的软件架构师、设计人员和编程人员而写的，同时也可作为高等院校计算机专业及软件学院相关课程的参考教材。

经常书评

目录

译者序
前言
模式列表
引言 1
0.1 架构 1
0.2 企业应用 2
0.3 企业应用的种类 3
0.4 关于性能的考虑 4
0.5 模式 6
0.5.1 模式的结构 7
0.5.2 模式的局限性 9

第一部分 表述
第1章 分层 12
1.1 企业应用中层次的演化 13
1.2 三个基本层次 14
1.3 为各层选择运行环境 15

第2章 组织领域逻辑 19
2.1 抉择 22
2.2 服务层 23

第3章 映射到关系数据库 25
.3.1 架构模式 25
3.2 行为问题 28
3.3 读取数据 29
3.4 结构映射模式 30
3.4.1 关系的映射 30
3.4.2 继承 33
3.5 建立映射 34
3.6 使用元数据 35
3.7 数据库连接 36
3.8 其他问题 38
3.9 进一步阅读 38

第4章 Web表现层 39
4.1 视图模式 41
4.2 输入控制器模式 43
4.3 进一步阅读 43

第5章 并发 45
5.1 并发问题 45
5.2 执行语境 46
5.3 隔离与不变性 47
5.4 乐观并发控制和悲观并发控制 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 业务事务和系统事务 53
5.6 离线并发控制的模式 54
5.7 应用服务器并发 55
5.8 进一步阅读 56

第6章 会话状态 57
6.1 无状态的价值 57
6.2 会话状态 58
6.3 存储会话状态的方法 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 深入到数据源层 68
8.2.1 事务脚本的数据源 68
8.2.2 表模块的数据源 69
8.2.3 领域模型的数据源 69
8.3 表现层 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章 数据源架构模式 101
10.1 表数据入口（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数据集（C#） 104
10.2 行数据入口（Row Data Gateway） 106
10.2.1 运行机制 107
10.2.2 使用时机 108
10.2.3 例：人员记录（Java） 108
10.2.4 例：领域对象的数据保持器（Java） 111
10.3 活动记录（Active Record） 112
10.3.1 运行机制 112
10.3.2 使用时机 113
10.3.3 例：一个简单的Person类（Java） 113
10.4 数据映射器（Data Mapper） 115
10.4.1 运行机制 116
10.4.2 使用时机 119
10.4.3 例：一个简单的数据映射器（Java）&nb

试读

　　我虽然没有从事过早期批处理系统时期的任何工作，但我认为当时的软件工作人员不会太关注层次的概念，只要编写操作某些文件（ISAM、VSAM等）格式的程序，这就是当时的应用。它不需要层次。

　　20世纪90年代，随着客户／服务器系统的出现，分层的概念更明显了。这样的系统是一种两个层次的系统：客户端包括用户界面和其他应用代码，服务器端通常是关系型数据库。常见的客户端工具如VB、PowerBuilder和Delphi。这些工具使得构建数据密集型应用非常容易。因为它们的用户界面控件通常都是SQL感知的。因此，可以通过将控件拖拽到“设计区域”来建立界面，然后再使用属性表单把控件连接到后台数据库。

　　如果应用仅仅包括关系数据的简单显示和修改，那么这种客户／服务器系统的工作方式非常合适。问题来自领域逻辑：如业务规则、验证、计算等。通常，人们会把它们写在客户端，但是这样很笨拙，并且往往把领域逻辑直接嵌入到用户界面。随着领域逻辑的不断复杂化，这些代码将越来越难以使用。而且，这样做很容易产生冗余代码，这意味着简单的变化都会导致要在很多界面中寻找相似代码。

　　另外一种办法是把这些领域逻辑放到数据库端，作为存储过程。但是，存储过程只提供有限的结构化机制，这将再次导致笨拙的代码。而且，很多人喜欢关系型数据库的原因之一是SQL是一个标准，允许他们更换数据库厂商。尽管真正更换数据库厂商的用户寥寥无几，但还是有很多人希望拥有这种选择，并且没有太大的附加代价。由于存储过程都是数据库厂商私有的，因此普通用户被剥夺了这种选择权。

　　在客户／服务器方式逐渐大众化的同时，面向对象方式开始崛起。面向对象为领域逻辑的问题找到了答案：转到三层架构的系统。在这种方式下，在表现层实现用户界面，在领域层实现领域逻辑，在数据源层存取数据。这种方式使你可以将复杂的领域逻辑从界面代码中抽取出来，单独放到中间层，用对象加以建模和组织。

 　　……

前言/序言

　　“每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动。”

　　—ChristopherAlexander

　　本书是面向对象大师MartinFowler继《AnalysisPatterns》、《UMLDistilled》、《PlanningExtremeProgramming》、《Refactoring》之后的又一力作。

　　“温故而知新”。Fowler在本书中再次向我们证明了《礼记》中这句古训的震撼力—他在回头审视自己及同仁多年来从事企业应用开发的经验和教训后，归纳总结了40多种企业应用架构的设计模式。这些模式从不同层次、不同侧面向我们展示了什么是好的企业应用架构？如何设计好的企业应用？

　　正如作者自己所言，企业应用在某些方面比其他软件（如电信通信软件）复杂得多：纷繁复杂的企业数据、“不合逻辑”的业务规则、变化莫测的用户需求，等等。环顾四周—CORBA、J2EE、.NET—企业应用开发技术可谓“前仆后继、层出不穷”，开发平台的种类之多就更不必说。

　　招式套路可以千变万化，扎实深厚的“内功”却是始终如一！虽然企业应用涉及的软件技术不断翻新，但是基本的架构及设计思想却没有太多变化。将以前行之有效的设计思路和方法加以适当调整，并应用到当前的问题上，是最高效的做法。在一组专家级合作者的帮助下，Martin将40多种经常出现的解决方案转化成模式，最终融会成这本“内功心法”。在仔细研读、用心揣摩本书之后，希望它能够帮助你应对任何一种企业应用平台，驾驭任何一种企业应用技术—无论是现在的技术还是未来的技术。

　　熟悉Fowler的读者都知道，这位大师的写作风格可谓是“深入浅出，娓娓道来”。本书也是一样。前8章是关于企业应用的背景知识，如分层架构、Web表现、业务逻辑、数据库映射、并发、会话、分布策略，等等。在此基础上，随后的各章分别对与这些背景知识相关的设计模式进行了详细的介绍。与其他设计模式的书一样，本书从模式的使用场景、解决方案、UML表示等方面予以介绍，详略有致。就连示例的编程语言的选取—Java和C#—也是与他的写作风格一脉相承的。

　　夜已深，窗外依旧是绵绵不断的早春小雨。让我们酌一杯清茶，一起来品味大师的话，一起来品味“源于实践、指导实践”的苦涩与甘甜—

　　“模式的关键点是它们源于实践。必须观察人们的工作过程，发现其中好的设计，并找出‘这些解决方案的核心’。这不是一个简单的过程，但是一旦发现了某个模式，它将是非常有价值的。对于我来说，价值之一是能够撰写这样一本参考书。你不必通读本书的全部内容，也不必通读任何一本有关模式的书。只需要了解到这些模式都是干什么的、它们解决什么问题、它们是如何解决问题的，就足够了。这样，一旦你碰到类似问题，就可以从书中找出相应的模式。那时，你再深入了解相应的模式也为时不晚。”