《企业应用架构模式（典藏版） [英]马丁·福勒》[69]百度网盘|亲测有效|pdf下载

产品特色

编辑推荐

大师经典之作
本书是世界著名软件开发大师Martin Fowler的经典作品之一。
40余种模式总结
几乎适用于任何企业应用平台。本书曾荣获《软件开发》杂志图书类的生产效率奖和读者选择奖。
以实践为导向
为每种模式给出了使用方法和实现信息，并配以详细的Java代码或C#代码示例。
经久不衰
畅销20余年。尽管技术本身存在变化，但基本的设计思想并没有太多变化，这些思想可以加以适当调整，用来解决那些共同的问题。

内容简介

本书是一部系统总结企业级软件架构方法、思想和模式的著作，被誉为“软件架构领域最重要的10本书之一”。原书被翻译为葡萄牙语、波兰语、德语、俄语、韩语、日语、简体中文等多种语言，畅销不衰，并曾获得美国《软件开发》杂志颁发的“Jolt生产效率奖”。
第一部分（第1～8章）介绍企业应用架构领域需要掌握的关键知识和可能遇到的问题，并给出了这些问题的初步解决方案；第二部分（第9～18章）在对这些解决方案进行细化的同时，总结出了51种实用的软件架构模式，每个模式都详细给出了使用场景、解决方案、UML表示等。
这些模式从不同层次、不同侧面展示了什么是好的企业应用架构，以及如何设计好的企业应用架构，不管企业应用开发的技术和平台如何变化，这些模式始终能在企业应用架构中发挥重要的作用，是不可或缺的内功心法。

作者简介

马丁·福勒（Martin Fowler）
世界著名软件开发大师，Thoughtworks首席科学家，从事软件开发相关工作30余年，是全球软件架构、敏捷开发、极限编程、设计模式等多个领域的领袖人物。此外，他在面向对象分析与设计、UML、数据库、领域特定语言等领域也有深厚的积累和卓越的贡献。
知名作家，著有多部在IT领域影响深远的著作，包括（部分）：
《分析模式：可复用的对象模型》
《UML精粹》
《领域特定语言》
《NoSQL精粹》
《重构：改善既有代码的设计》

显示全部信息

目　　录

目　　录Contents
译者序
前言
模式列表
引言　1
0.1　架构　1
0.2　企业应用　2
0.3　企业应用的种类　4
0.4　关于性能的考虑　5
0.5　模式　7
0.5.1　模式的结构　8
0.5.2　模式的局限性　9
第一部分　表　　述
第1章　分层　12

目　　录Contents 译者序 前言 模式列表 引言　1 0.1　架构　1 0.2　企业应用　2 0.3　企业应用的种类　4 0.4　关于性能的考虑　5 0.5　模式　7 0.5.1　模式的结构　8 0.5.2　模式的局限性　9 第一部分　表　　述 第1章　分层　12 1.1　企业应用中层次的演化　13 1.2　三个基本层次　14 1.3　为各层选择运行环境　16 第2章　组织领域逻辑　18 2.1　抉择　21 2.2　服务层　22 第3章　映射到关系数据库　24 3.1　架构模式　24 3.2　行为问题　28 3.3　读取数据　29 3.4　结构映射模式　30 3.4.1　关系的映射　30 3.4.2　继承　32 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　进一步阅读　44 第5章　并发　45 5.1　并发问题　46 5.2　执行语境　47 5.3　隔离与不变性　48 5.4　乐观并发控制和悲观并发控制　48 5.4.1　避免不一致读　49 5.4.2　死锁　50 5.5　事务　51 5.5.1　ACID　52 5.5.2　事务资源　52 5.5.3　减少事务隔离以提高灵活性　53 5.5.4　业务事务和系统事务　54 5.6　离线并发控制的模式　55 5.7　应用服务器并发　56 5.8　进一步阅读　57 第6章　会话状态　58 6.1　无状态的价值　58 6.2　会话状态　59 6.3　存储会话状态的方法　60 第7章　分布策略　63 7.1　分布对象的诱惑　63 7.2　远程接口和本地接口　64 7.3　必须使用分布的情况　65 7.4　关于分布边界　66 7.5　分布接口　67 第8章　通盘考虑　68 8.1　从领域层开始　69 8.2　深入到数据源层　70 8.2.1　事务脚本的数据源　70 8.2.2　表模块的数据源　70 8.2.3　领域模型的数据源　70 8.3　表示层　71 8.4　一些关于具体技术的建议　72 8.4.1　Java和J2EE　72 8.4.2　.NET　73 8.4.3　存储过程　73 8.4.4　Web Services　74 8.5　其他分层方式　74 第二部分　模　　式 第9章　领域逻辑模式　78 9.1　事务脚本　78 9.1.1　运行机制　78 9.1.2　使用时机　79 9.1.3　收入确认问题　80 9.1.4　例：收入确认（Java）　81 9.2　领域模型　83 9.2.1　运行机制　84 9.2.2　使用时机　86 9.2.3　进一步阅读　86 9.2.4　例：收入确认（Java）　86 9.3　表模块　90 9.3.1　运行机制　91 9.3.2　使用时机　93 9.3.3　例：基于表模块的收入 确认（C#）　93 9.4　服务层　96 9.4.1　运行机制　97 9.4.2　使用时机　99 9.4.3　进一步阅读　100 9.4.4　例：收入确认（Java）　100 第10章　数据源架构模式　103 10.1　表数据入口　103 10.1.1　运行机制　103 10.1.2　使用时机　104 10.1.3　进一步阅读　105 10.1.4　例：人员入口（C#）　105 10.1.5　例：使用ADO.NET 数据集（C#）　107 10.2　行数据入口　109 10.2.1　运行机制　110 10.2.2　使用时机　110 10.2.3　例：人员记录（Java）　111 10.2.4　例：领域对象的数据 保持器（Java）　114 10.3　活动记录　115 10.3.1　运行机制　115 10.3.2　使用时机　116 10.3.3　例：一个简单的Person类 （Java）　116 10.4　数据映射器　118 10.4.1　运行机制　119 10.4.2　使用时机　122 10.4.3　例：一个简单的数据 映射器（Java）　123 10.4.4　例：分离查找器（Java）　127 10.4.5　例：创建一个空对象 （Java）　130 第11章　对象－关系行为模式　132 11.1　工作单元　132 11.1.1　运行机制　132 11.1.2　使用时机　136 11.1.3　例：使用对象注册的工作 单元（Java）　137 11.2　标识映射　140 11.2.1　运行机制　141 11.2.2　使用时机　143 11.2.3　例：标识映射中的方法 （Java）　143 11.3　延迟加载　144 11.3.1　运作机制　144 11.3.2　使用时机　146 11.3.3　例：延迟初始化（Java）　146 11.3.4　例：虚代理（Java）　147 11.3.5　例：使用值保持器（Java）　148 11.3.6　例：使用重影（C#）　149 第12章　对象－关系结构模式　156 12.1　标识字段　156 12.1.1　工作机制　156 12.1.2　使用时机　159 12.1.3　进一步阅读　160 12.1.4　例：整型键（C#）　160 12.1.5　例：使用键表（Java）　161 12.1.6　例：使用组合键（Java）　163 12.2　外键映射　172 12.2.1　运行机制　173 12.2.2　使用时机　175 12.2.3　例：单值引用（Java）　176 12.2.4　例：多表查询（Java）　178 12.2.5　例：引用集合（C#）　179 12.3　关联表映射　182 12.3.1　运行机制　182 12.3.2　使用时机　183 12.3.3　例：雇员和技能（C#）　183 12.3.4　例：使用直接的SQL （Java）　186 12.3.5　例：用一次查询查多个 雇员（Java）　189 12.4　依赖映射　193 12.4.1　运行机制　193 12.4.2　使用时机　194 12.4.3　例：唱片和曲目（Java）　195 12.5　嵌入值　197 12.5.1　运行机制　198 12.5.2　使用时机　198 12.5.3　进一步阅读　199 12.5.4　例：简单值对象（Java）　199 12.6　序列化LOB　200 1

显示全部信息

前　　言

Preface前　　言
1999年春天，我飞抵芝加哥为Thoughtworks公司正在开发的一个项目担任顾问。Thoughtworks是一个规模虽小但正在快速成长的应用开发公司。这个项目属于那种极富挑战性的企业级应用，它是一个后端租赁系统。简单来说，它处理的是租户签字认可后所有与租赁有关的事务，包括发送账单、处理某些人对所租房屋资产的改造、追踪那些未按时缴纳账单的租户、指出如果某人提前归还资产应当如何处理等。在你意识到租赁合同极度复杂并且总在不断变化之前，这听起来好像并不太难实现。它的业务逻辑几乎不能套用任何已有的逻辑模式，因为那些逻辑归根到底是商人为争夺生意而制定的，一些古怪的小改动都可能对赢得某笔交易起关键作用。因此，每次生意上的一点点胜利就意味着系统复杂性的又一次增加。
我对此类问题情有独钟：如何捕获这些复杂性，并设计一个面向对象的系统来处理它们。事实上，我一直坚信面向对象的最大优点在于它能够使复杂逻辑易于处理。为复杂业务逻辑开发一个良好的领域模型很困难，但在此问题中却是恰得其所。

Preface前　　言 1999年春天，我飞抵芝加哥为Thoughtworks公司正在开发的一个项目担任顾问。Thoughtworks是一个规模虽小但正在快速成长的应用开发公司。这个项目属于那种极富挑战性的企业级应用，它是一个后端租赁系统。简单来说，它处理的是租户签字认可后所有与租赁有关的事务，包括发送账单、处理某些人对所租房屋资产的改造、追踪那些未按时缴纳账单的租户、指出如果某人提前归还资产应当如何处理等。在你意识到租赁合同极度复杂并且总在不断变化之前，这听起来好像并不太难实现。它的业务逻辑几乎不能套用任何已有的逻辑模式，因为那些逻辑归根到底是商人为争夺生意而制定的，一些古怪的小改动都可能对赢得某笔交易起关键作用。因此，每次生意上的一点点胜利就意味着系统复杂性的又一次增加。 我对此类问题情有独钟：如何捕获这些复杂性，并设计一个面向对象的系统来处理它们。事实上，我一直坚信面向对象的最大优点在于它能够使复杂逻辑易于处理。为复杂业务逻辑开发一个良好的领域模型很困难，但在此问题中却是恰得其所。 当然，单纯的领域模型也并非灵丹妙药。我们的领域模型必须持久化到数据库中，但是与许多项目一样，我们当时使用的是关系数据库。我们还必须将该模型与用户界面关联起来，还要能支持远程应用程序对本软件的使用，同时还必须将我们的软件与第三方的软件包整合。这些工作都基于一种被称为J2EE的新技术，当时全世界没有人在这一方面有实战经验。 虽然J2EE是一项崭新的技术，但我们仍能从以往的经验中得到帮助。本人曾经长期使用C 、Smalltalk和CORBA来开发类似系统。Thoughtworks公司中的许多人则有Forte方面的经验。可以说当时我们对关键架构已经有了思路，所要解决的仅是如何将之转化为J2EE实现。现在回过头来看三年前的设计，虽然它并不尽善尽美，但无疑经受住了时间的考验。 上述情况正是我撰写这本书的出发点。多年来，我看到过许多企业级应用项目。这些项目通常都包含相似的设计思路，这些设计思路已经被证明可以有效地处理企业应用中不可避免的复杂性。本书就是将这些设计思路升华为模式的一个起点。 本书分为两部分，第一部分是一些叙述性的章节，它们主要讨论企业应用设计中的一些重要议题。这些章节介绍了企业应用架构的各种问题，并给出了大体的解决方案。而解决方案的细节则在本书的第二部分以模式的方式组织成文。这些模式仅仅是一些参考，我并不希望读者一页页地细读。我的想法是：从头到尾将第一部分的叙述性章节读完，然后再根据兴趣和需求翻阅第二部分的有关章节。因此，本书将简短的叙述和详尽的参考合二为一。 本书讨论的是企业级应用的设计。企业级应用涉及大量复杂数据的显示、操作和存储以及对这些数据进行处理的业务流程的自动化。典型的例子有预订系统、金融系统、物流补给系统以及其他种种驱动现代商业运作的系统。企业级应用和嵌入式系统、控制系统、电信系统或者桌面应用程序不同，它们有自己特有的挑战和解决方案。因此，如果你不是在企业领域工作，本书对你并没有益处（除非想体会一下企业级应用是怎么一回事）。如果需要一本关于软件架构的通用性的书籍，我推荐［POSA］?。 在构建企业级应用时有许多架构方面的问题，我想本书恐怕很难一一详细列举。在软件开发方面，本人是迭代开发方法的忠实信徒。迭代开发的核心在于只要软件对用户有用，就应当交付，即使这个软件当时并没有完成。虽然著书与编写软件之间存在诸多差异，但我认为在这一点上异曲同工。也就是说，虽然本书尚不全面，但已具雏形，可以为读者提供有关企业应用架构方面的有益建议（至少我认为如此）。本书讨论的主要议题是： 企业级应用的分层 构建领域（业务）逻辑 构建基于Web的用户界面 将内存模块（尤其是对象）关联到关系数据库 在无状态环境下处理会话状态 分布原则 本书未涉及的议题很多，我很想撰写关于组织确认、合并消息和异步通信、安全、错误处理、集群、应用集成、架构重构、构建富客户的用户界面等方面的书籍或文章；但是，由于时空限制以及思路尚未成熟，本书将不涉及上述内容。我只能希望在不久的将来能看到一些与这些工作相关的模式。也许我会撰写本书的第2卷并加入这些内容，或者是由其他人来补遗。 当然，基于消息的通信是相当重要的问题。在进行多应用程序集成时，人们正越来越多地用到异步的、基于消息的通信方法。即便是在同一应用程序内部，基于消息的通信也值得费上一些笔墨。 本书并非针对某一特定的软件平台。从20世纪80年代末到90年代初，我开始在基于Smalltalk、C 和CORBA的项目中使用这些模式。而20世纪90年代后期我在Java方面做了大量的工作，我发现这些模式可以很好地应用于较早的Java/CORBA系统和其后基于J2EE的工作中。近来，我开始在微软的.NET平台方面做一些探索，我发现这些模式同样有效。Thoughtworks公司的同事也介绍了他们的经验，尤其是在Forte方面。我不敢说这些模式能够适用于所有已经和即将被用于企业级应用的开发平台，但至少到目前为止，它们已经表现出足够的可重用性。 对于大多数模式，本书提供了相应的代码示例。这些示例所用的编程语言是我认为大多数读者都能够阅读和理解的语言。Java就是一个很好的选择，只要熟悉C或C 就可以读懂Java代码，Java远没有C 那么复杂。基本上，大多数C 程序员都能够理解Java，但反过来却并非如此。我是面向对象的信徒，也就自然更偏爱面向对象的语言。因此，大多数代码示例使用的是Java语言。写这本书时，微软的.NET环境正逐渐成熟，它的C#语言与Java有许多相同之处。所以某些代码示例也使用了C#语言，虽然这样做会多少有一些风险，因为.NET尚未得到大量应用，使用的术语可能尚未形成惯例。这两种语言都是基于C的，只要能读懂其中一种，即使对另一种语言或平台并不熟悉，要读懂它也并非难事。我的目的是使用一种能够让最多的软件开发者读懂的语言，即使这种语言并非他们所擅长或偏爱的。（谨向那些喜欢Smalltalk、Delphi、Visual Basic、Perl、Python、Ruby、COBOL或其他语言的读者致歉。我知道你们认为有比Java或C#更好的语言，我也认为如此！） 示例是用来阐述和解释模式思想的，它们并非可以直接使用的解决方案，任何情况下都需要做一些工作才能将它们用于你的应用程序之中。模式只是一个有益的起点，而非最终的解决之道。 本书的读者 本书面向的是正在构建企业级应用并希望增进对架构相关问题的理解和沟通的编程人员、设计人员和软件架构师。 我假定本书的大多数读者可以归为两类：一类是所面对的需求并非大规模的，因此准备自己从零开始构建软件；另一类是有大规模的需求，将使用某些工具。对于前者，我认为本书中提及的模式将有助于工作的启动。尽管在许多领域，所需的知识远超出本书中模式所给予的内容，但本书提供了一个比我当初进入该领域时更高的起点。对于那些工具的使用者，我希望本书能揭开工具的一些内幕，帮助他们决策选择使用哪一种工具所支持的模式。例如，使用对象-关系映射工具同时意味着你必须决定如何映射某些特定情况。本书所提供的模式将有助于你做出这样的决策。 当然，还可能有第三类读者，他们强烈希望亲自构建软件。在此，我首先要忠告他们的是：请先考虑使用已有的工具。我见过不止一个项目花费了大量时间来构建框架，而这些框架并非该项目所真正要解决的问题。如果你仍固执己见，那也只能听天由命。但要记住，本书中的代码示例为提高可理解性都被有意简化过，在实际使用时，往往需要对它们大动干戈才能满足要求。 由于模式是可复现问题的通用解决方案，因此可能有的读者已经对这些模式有所接触。如果你从事企业级应用开发已经有一段时间，那么可能会很熟悉其中大部分模式。本书中并不包含任何新的东西，正相反：这是一本关于（我们这一行业的）已有知识的书。如果你是这一领域的新手，我希望本书将帮助你学习这些技术。如果你熟悉这些技术，我希望本书有助于你与其他人沟通。模式的重要作用就在于其创建了一个通用的词汇表，例如，你称某个类是远程外观，其他设计人员就都知道你指的是什么。 致谢 与其他书籍一样，本节将涉及多年来以不同方式与我一起工作的很多人。他们以许多方式对本书提供过帮助。本书中一些重要内容是由他人提供的，其中有些人我可能已经无法回忆起他们的名字。在这里，我所能做的就是对那些仍铭记在心的人表示感谢。 首先要感谢我的合作者David Rice，他是我在Thoughtworks公司的同事，他为本书做出了巨大的贡献：撰写了本书的1/10。当我们努力保证本书能如期交付时（他当时还要从事客户支持的工作），我们曾在若干个深夜通过即时消息进行协商，因此他坦承总算明白了为何写一本书是如此困难却又如此吸引人。 Matt Foemmel是我在Thoughtworks公司的另一个同事。尽管他文笔犀利冷峻，是本书的一个十分中肯的批评家，但他为代码示例做出了很大的贡献。Randy Stafford为本书贡献了服务层模式，他一直是此模式的极力倡导者。我还要感谢Edward Hieatt和Rob Mee所做的贡献，特别是Rob在复审本书时所发现的缺失。Rob是我的最佳审阅者：他不仅发现少了某些内容，而且他还帮我写了一节来弥补这个缺失！ 同样，对本书一流的正式审阅者，我的言辞远不能表达我的感激之情： John Brewer　　Rob Mee Kyle Brown　　Gerard Meszarios Jens Coldewey　　Dirk Riehle John Crupi　　Randy Stafford Leonard Fenster　　David Siegel Alan Knight　　Kai Yu 我几乎要把Thoughtworks公司的电话号码簿列在此处了，因为太多同事与我讨论过他们的设计和经验，在这一项目上帮助过我。许多模式之所以能在我脑中成型，是因为我有机会与众多天才设计师讨论，因此我只好对整个公司表示感谢。 Kyle Brown、Rachel Reinitz和Bobby Woolf在百忙之中抽出时间与我一起在北卡罗来纳对本书进行了长期而细致的审阅。本书中注入了他们的睿智，尤其是与Kyle的几次长时间的电话交谈令我获益匪浅。 2000年初，我与Alan Knight和Kai Yu一起为Java One大会准备了一个演讲，这是本书最初的雏形。在对他们所提供的帮助致谢的同时，我还要感谢Josh Mackenzie、Rebecca Parsons和 Dave Rice，他们其后协助我提炼了这些演讲及其思想。Jim Newkrik付出了很大努力协助我熟悉.NET平台。 我与这个领域的许多专家有过令人惬意的交谈和合作，在他们身上学到了不少东西。尤其想对Colleen Roe、David Muirhead和Randy Stafford表示感谢，他们将自己在Gemstone的Foodsmart示例系统上的工作成果与我共享。我在Bruce Eckel所主持的Crested Butte讨论会上也参与过一些重要的会谈，因此应当向近年来这一会议的与会者致谢。Joshua Kerievsky虽然没有时间对本书做一次全面的审阅，但他是模式方面的优秀顾问。 我还从UIUC阅读组那里获得了相当大的帮助，他们作为读者对本书提出了坦诚的批评。我要感谢Ariel Gertzenstein、Bosko Zivaljevic、Brad Jones、Brian Foote、Brian Marick、Federico Balaguer、Joseph Yoder、John Brant、Mike Hewner、Ralph Johnson和 Weerasak Witthawaskul。 前UIUC成员Dragos Manolescu及其小组给了我一些反馈。感谢Muhammad Anan、Brian Doyle、Emad Ghosheh、Glenn Graessle、Daniel Hein、Prabhaharan Kumarakulasingam、Joe Quint、John Reinke、Kevin Reynolds、 Sripriya Srinivasan和 Tirumala Vaddiraju。 Kent Beck为我提供了许多思路，尤其是他为特殊情况模式所起的名字。Jim Odell将我领入了顾问咨询、教学和写作的世界，我由衷地感谢他。 当我写这本书时，曾将草稿放在Web上。期间许多人通过电子邮件向我指出问题、提出疑问或者讨论其他替代方案。他们中有Michael Banks、Mark Bernstein、Graham Berrisford、Bjorn Beskow、Bryan Boreham、Sean Broadley、Peris Brodsky、Paul Campbell、Chester Chen、John Coakley、Bob Corrick、Pascal Costanza、Andy Czerwonka、Martin Diehl、Daniel Drasin、Juan Gomez Duaso、Don Dwiggins、Peter Foreman、Russell Freeman、Peter Gassmann、Jason Gorman、Dan Green、Lars Gregori、Rick Hansen、Tobin Harris、Russel Healey、Christian Heller、Richard Henderson、Kyle Hermenean、Carsten Heyl、Akira Hirasawa、Eric Kaun、Kirk Knoernschild、Jesper Ladegaard、Chris Lopez、Paolo Marino、Jeremy Miller、Ivan Mitrovic、Thomas Neumann、Judy Obee、Paolo Parovel、Trevor Pinkney、Tomas Restrepo、Joel Rieder、Matthew Roberts、Stefan Roock、Ken Rosha、Andy Schneider、Alexandre Semenov、Stan Silvert、Geoff Soutter、Volker Termath、Christopher Thames、Volker Turau、Knut Wannheden、Marc Wallace、Stefan Wenig、Brad Wiemerslage、Mark Windholtz、Michael Yoon。 此外，还有许多我不认识或已经遗忘了的人，在此要向他们表达同样真诚的谢意。 最诚挚的谢意依旧要献给我的妻子Cindy，她与我同历风雨，我将永远铭刻在心。

显示全部信息