《微软应用架构指南 (第2版)》 - 学习笔记

**《微软应用架构指南 (第2版)》

========== ========== ==========
[做者] (美) Patterns & Practices
[译者] (中) 朱晔 高翔 王敏
[出版] 电子工业出版社
[版次] 2010年11月 第1版
[印次] 2010年11月 第1次 印刷
[订价] 69.00元
========== ========== ==========

【前言】

(P001)

开发人员和方案解决架构师一般是游走在“黄金方案”和“即时方案”之间。

架构就是利用现有的技术和工具来创造尽量多的商业价值，一方面关注现有业务所提出的需求和限制，另外一方面着眼于将来经过可伸缩性、灵活性以及可维护性等方面最大化价值。

【第01章】 【什么是软件架构】

(P003)

软件应用架构是一个结构化解决方案，这种结构化解决方案一方面能够知足全部技术和运营需求，另外一方面能够知足常见的质量特性 (quality attribute) 要求，例如性能、安全以及可管理性等。它涵盖了受多重因素影响的一系列决策，每种决策对质量、性能、可维护性及应用程序整体的成功都有至关大的影响。

(P004)

一个失败的架构带来的风险包括软件不稳定、不能支持既有或未来的业务需求、或难以在生产环境中部署和管理。

系统在设计的时候须要考虑用户、系统 (IT基础结构) 和业务。对于每个方面，您都应该列出关键应用场景，并找出重要质量特性 (例如可靠性或可伸缩性) 和使人满意或不满意的关键点。若是可能的话，在每个须要考虑的方面，都创建衡量得失的标准。

架构关注构成应用程序的主要元素和组件的使用和它们之间的交互。而设计则主要关注与数据结构和算法的选择，以及组件细节的实现。

架构师必须考虑设计决策致使的整体效果，以及与生俱来的权衡，包括众多质量属性之间的权衡和用户、系统和业务需求之间的权衡。

要记住，架构应该 :

1. 展现系统的结构可是隐藏实现细节；
2. 意识到全部用例和应用场景；
3. 力求顾及各参与者的需求；
4. 处理功能和质量需求；

(P005)

使用那些在大量解决方案中通过验证的，能够解决常见问题的模式。

不要对架构进行过分设计，尤为是不要针对那些没法验证的事情作出任何假设，咱们只须要在设计的过程当中为未来可能的变化留出余地便可。

【第02章】 【软件架构的关键原则】

(P007)

架构注重把组件进行组织以支持特定功能。

(P008)

在设计应用程序或系统的时候，软件架构师的目标是经过把设计分割为不一样的关注点来尽可能减小复杂度。

对于每个点，咱们设计的组件就关注此特定点，不该混合其余关注点的代码。

(P009)

关注点分离 —— 把您的应用程序分解为尽量不发生功能重叠的不一样特性。这样作最大的好处是某个特性或功能能够独立于其余特性或功能进行优化。

明确层之间如何通讯 —— 若是容许应用程序中的层和其余全部层进行通讯或依赖，可能会致使解决方案更难理解和管理，须要考虑清楚层间的依赖和层与层间数据的流动。

组件或对象不该该依赖其余组件或对象的内部细节 —— 每个组件或对象应该只调用另外一个组件或对象的一个方法，而且这个方法知道如何处理请求，如何把它转发到合适的子组件或其余组件，这有助于建立可维护性和可适应性更高的应用程序。

(P010)

确保横切代码尽量从应用程序业务逻辑中抽象出来 —— 横切代码指的是有关于安全、通讯或诸如日志和指示器等运营管理的代码。

(P011)

每个应用程序设计都必须考虑安全性和性能，但不是每个设计都须要考虑互操做性和可伸缩性。

【第03章】 【架构模式和风格】

(P013)

架构风格 (architectural style) 有时候又被称做架构模式，它是一组原则 —— 为一族 (a family of) 系统提供抽象框架的粗粒度的模式。

理解架构风格有不少好处，最大的好处在于它提供了通用表达方式，还为技术无关的讨论提供了机会，能让咱们在不涉及具体细节的状况下针对模式和原则进行高层的讨论。

(P014)

软件系统的架构几乎都不会局限于单个架构风格，而一般是使用架构风格的组合来构成完整的系统。

(P016)

最简单的 客户端 / 服务端 系统包含了能够由多个客户端直接访问的服务端应用程序，也称做两层架构风格。

(P017)

可使用诸如依赖注入 (Dependency Injection) 模式或者是服务定位器 (Service Locator) 之类的设计模式来管理组件之间的依赖关系，而且提供松散的耦合和重用。

(P018)

为应用程序进行正确的分层能够帮助您有效地分离关注点，从而增进灵活性和可维护性。

分层架构风格一般称为重用的倒金字塔 (inverted pyramid of reuse) ，每一层对直接下层的职责和抽象进行聚合。对于严格的分层结构来讲，层中的组件只能和相同层或直接下层中的组件进行交互，而较松散的分层结构则容许层中的组件和相同层以及任何下属层中的组件进行交互。

应用程序的层可能放在相同的物理机器上 (相同物理层) 或是分布在独立的机器上 (N 物理层)，而且每一层中的组件经过明肯定义的接口来和其余层中的组件进行通讯。

可重用 —— 下层对上层没有依赖，这也就使得下层能够在其余应用场景中被重用。

松耦合 —— 层之间的通讯基于抽象和事件，这也就提供了层和层之间的松耦合。

(P019)

性能 —— 经过把逻辑层分布到多个物理层中能够提升扩展性、容错性 (fault tolerance) 和性能。

(P020)

消息总线架构一般使用消息路由或 发布 / 订阅 模式，而且一般使用诸如消息队列的消息系统来实现。

复杂的处理逻辑 —— 能够经过整合一组小的操做来构成复杂操做，每个小操做都完成特定任务，多个小操做组合成一个多步操做。

(P021)

N 层或三层是一种架构部署风格，它以一种和分层风格很类似的方式把功能分割为不一样的片断，只不过每一个片断做为一个物理层，将会分布在物理上分离的计算机上。它从面向组件的方式发展而来，一般使用特定于某个平台的方式而不是基于消息的方式来通讯。

N 层应用架构的主要特征是 : 应用程序功能分离，服务组件、组件的分布式部署，提供加强的可伸缩性、可用性、可管理性及充分利用资源。除了直属上层和下层以外，每个物理层彻底独立于其余的层。n 层只知道如何处理 n+1 层的请求，如何把请求返回给 n-1 层 (若是有的话) ，以及如何处理请求的结果。通常层之间的通讯是异步的，以便更好地支持可伸缩性。

N 层架构一般至少有三个分离的逻辑部分，每一部分都部署于独立的物理服务器上，每一部分负责特定的功能。在使用分层设计方式的时候，若是有超过一个服务或应用程序使用逻辑层的功能就把它部署为物理层。

N 层 / 三层 架构风格的主要优点在于 :

1. 可维护性 —— 因为每一层相对于其余层来讲是独立的，更新或修改部分都不会对整个应用程序发生影响；

2. 可伸缩性 —— 因为物理层基于逻辑层来部署，横向扩展应用程序就变得至关简单；

3. 灵活性 —— 因为每一层都独立管理和扩展，也就增长了灵活性；

4. 可用性 —— 应用程序可使用易于扩展的组件来造成模块化的系统，增长了可用性；

(P022)

经过使用一系列的协议和数据格式来交流信息， SOA 架构风格能够把业务处理包装成可互操做的服务，客户端和其余服务能够访问运行于相同物理层的本地服务，也能够经过链接的网络访问远程服务。

【第04章】 【架构和设计的方法】

(P026)

架构过程应该是迭代和增量的方式。

(P027)

在架构和设计的过程当中，用例 (use case) 描述的是一组交互行为，它能够是系统和一个或多个因素 (用户或另一个系统) 之间的交互。而应用场景 (scenario) 描述的是广义上用户和系统的交互，这种交互并不经过用例的路径。

(P028)

架构风格是一组原则。您能够把它认为是一个粗粒度的模式，它能够为一族系统提供抽象框架。每个风格定义了一组规则，它指定构成系统的组件类型、组件之间的关系、组装方式的约束以及组装时使用的一些假想。

架构风格能够提升系统的分层程度，而且经过为常常发生的问题提供解决方案来提高设计的重用性。

应用程序每每使用多个风格的组合。

(P029)

在选择您设计中会使用的技术的时候，您须要考虑哪些技术能够支持所选的架构风格、应用程序类型及应用程序的关键质量特性。

是否能够画出架构很重要。

【第05章】 【分层应用程序指导原则】

(P039)

层关注的是组件和功能的逻辑划分 (logical division) ，不考虑组件的物理位置。层能够位于不一样的物理层也能够属于相同的物理层。

咱们须要理解逻辑层 (layer) 和物理层 (tier) 的区别。逻辑层描述的是应用程序中功能和组件的逻辑分组；而物理层 (Tier) 描述的是把功能和组件从物理上分布到独立服务器、计算机、网络或远程位置。

把超过一个逻辑层放在同一个物理机器上 (一个物理层) 很常见。

层有助于区分组件进行的不一样类型的任务，这样使得咱们的设计能够很容易支持组件重用。

每个逻辑层包含许多独立的组件类型并分组成子层，每个子层执行特定类型的任务。

把应用程序分割为具备不一样角色和不一样功能的层不只有助于最大化代码的可维护性，并且能经过改变部署方式最优化应用程序的工做方式，以及提供一个清晰的描述展现各个位置上必须实现的技术或设计决策。

从最高级的和最抽象的角度来讲，任何系统在逻辑架构层面均可以看做是把一组相互协做的组件分组成逻辑层。

(P040)

表现层 —— 这个层包含面向用户的功能，负责管理用户和系统之间的交互，一般还包含一些组件，咱们能够利用这些组件来访问封装在业务层的核心业务逻辑。

业务层 —— 这个层实现了系统的核心功能而且封装了相关业务逻辑。它一般由一些组件构成，一些组件可能会暴露服务接口供其余调用者使用。

数据层 —— 这一层提供针对寄存在系统边界内的或者由其余联网系统暴露的数据的访问，这种访问多是经过服务的方式进行的。

从较高的层面来看，基于服务的解决方案能够看做是由多个服务构成，每个服务经过传递消息和其余服务进行通讯。从概念上来讲，服务能够看做是整个解决方案的一些组件。然而，在内部每个服务和其余任何应用程序同样都由软件组件构成，而且这些组件能够在逻辑上分组为表现层、业务层和数据层。

(P041)

若是应用程序必须为其余应用程序提供服务，或者要实现一些直接提供给客户端的特性，一般的方式就是使用服务层来暴露应用程序的业务功能。

(P042)

在设计应用程序的时候，第一件事情就是关注最高层次的抽象，也就是功能的分层，而后必须为每一层 (取决于设计的应用程序的类型) 定义公共接口。定义了层和接口以后，还必须决定应用程序的部署方式，最后选择要使用的通讯协议，用于逻辑层和物理层之间的交互。

使用分层的方式能够改善应用程序的可维护性，而且在须要改善性能的时候能够更方便地进行横向扩展 (scale out) 。

肯定分层策略中相当重要的第一步就是为应用程序肯定合适的分层粒度。

(P043)

为了保持灵活性，老是须要确保层之间的交互是松耦合的。

采用分层方式会增长一些复杂度，而且可能会增长初始的开发时间，可是若是正确实施的话，会极大提升应用程序的可维护性、可扩展性和灵活性。必须在重用性、松耦合和影响性能、增长复杂度之间进行权衡选择。整体上来讲，分层设计提供的灵活性和可维护性的优点远远超过了使用不分层的紧密耦合设计带来微弱的性能上的提高。

业务应用程序中最多见的做法是把表现、服务、业务和数据访问功能分红独立的层。一些应用程序还引入报表、管理或基础结构层。

若是须要增长层的话请慎重考虑，若是对相关联的组件进行逻辑分组不能明确增长应用程序可维护性、可伸缩性或灵活性的话，就不该该增长层。

只有在必要的时候才应该跨越独立的物理层来分布逻辑层和组件。

(P044)

找出应用程序中全部横切关注点很重要，尽量为每个关注点设计独立的组件。这种方式能够帮助您得到更好的重用性和维护性。

在为层定义接口的时候，首要的目标是实现层之间的松耦合。也就是说层不该该暴露内部细节让其余层进行依赖。而是应该设计层的接口，经过提供可以隐藏层中组件细节的公共接口来最小化依赖。这种隐藏称做抽象 (abstraction) ，而且有不少不一样的方式来实现。

(P045)

一个层不会依赖于另一个层，层都依赖于公共接口。

【第06章】 【表现层指导原则】

(P047)

表现层包含的组件能够实现和显示用户界面而且管理用户交互。它包含一些用于用户输入和显示的控件及一些组织用户交互的组件。

(P049)

缓存是用来提升应用程序性能和 UI 响应速度最好的方法之一。

(P050)

对长时间运行的行为，要为用户提供进度反馈。考虑容许用户取消长时间运行的操做。

(P051)

除非捕获的异常能处理，不然别随便使用自定义的异常，而且不要使用异常来控制应用程序的逻辑流程。

(P052)

输入验证应该由表现层来处理，而业务规则验证应该由业务层来处理。

若是您的业务层和表现层在物理上是分离的，业务规则的验证逻辑还应该在表现层也实现一份，以提升可用性和响应速度。

(P055)

对于 ASP.NET ，要当心地使用 ViewState ，由于它可能会在每一次往返中增长数据量，下降应用程序的性能。应考虑配置页面使用只读会话，甚至能够的话，考虑不使用会话。

【第07章】 【业务层指导原则】

(P060)

要最大化重用，业务逻辑组件不该该包含任何只能用于特定用例或应用场景的行为或应用程序逻辑。

在设计业务层的时候，软件架构师的目标是经过把任务分红不一样的关注点来最小化复杂度。

对于每个点，您设计的组件都应该关注在特定点上，而且不该该包含和其余关注点相关的代码。

应该尽量使用独立的业务层来提升应用程序的可维护性。

若是业务层会同时被表现层和外部应用程序使用，就能够选择经过服务来展现业务层。

(P061)

为业务层建立接口的时候使用抽象原则最小化耦合。抽象的技术包括使用公共对象接口，通用接口定义，抽象基类或消息。

为业务层设计有效的身份验证策略对应用程序的安全性和可靠性很重要。

为业务层设计有效的受权策略对应用程序的安全和可靠性很重要。

(P062)

对于角色，应考虑尽量让粒度变小以减小须要的权限组合数量。

为业务层设计合适的缓存策略对于应用程序的性能和响应速度很重要。

只缓存很是必要的数据。

在为业务层设计组件的时候，应确保它们是高内聚的，而且层间是低耦合的。这样就能够提升应用程序的可扩展性。

(P063)

为业务层设计有效的异常管理解决方案对应用程序的安全性和可靠性很重要。

为业务层设计有效的日志、审计和度量解决方案对应用程序的安全性和可靠性很重要。

为业务层设计有效的验证解决方案对应用程序的可用性和可靠性很重要。

【第08章】 【数据层指导原则】

(P068)

必须肯定一个策略来从数据源填充业务实体或数据结构，而且让应用程序的业务层或表现层来使用。

(P069)

批量处理数据库命令能够提高数据层的性能。每一次对数据库执行环境的请求都产生一次开销。经过批量化能够提升吞吐量、减小延迟以下降总开销。由于数据库能够为相近的查询缓存而且重用执行计划，因此批量处理类似查询能够提高性能。

(P070)

若是数据以数据流形式来存储和获取，能够认为这是二进制大对象或 BLOB 。

BLOB 通常用来存储图片数据，可是还能够用来保存对象的二进制表示。

选择合适的数据格式来提供和其余应用程序进行互操做的机制，以及利用序列化来跨进程和跨物理机器进行通讯。数据格式和序列化特别重要的另一个缘由是能让业务层存储和获取应用程序状态。

(P071)

尽量在贯穿应用程序的横切组件中集中进行异常处理逻辑。

(P072)

从存储过程的安全和性能来讲，原则上应该使用参数化查询和避免存储过程当中构建动态 SQL 。

要记住在存储过程当中使用动态 SQL 可能会影响性能、安全性和可维护性。

(P073)

事务是把一组有序信息的交换和相互关联的行为看成原子单元，以知足请求和确保数据库完整性。只有当全部的信息和行为都完成，而且相关数据库改变永久生效的时候，才认为事务完成了。在遇到错误时，事务支持撤销 (回滚) 数据库行为，这有助于保持数据库中数据的完整性。

(P074)

默认状况下微软 SQL Server 数据库为每个单独的 SQL 语句做为一个单独的事务来执行 (自动提交事务的模式) 。

设计有效的输入和数据验证策略对于应用程序的安全相当重要。

(P075)

DataReader 很是适合只读向前的、每一行都能快速处理的操做。

若是您访问的是 SQL Server 2008 ，可用 FILESTREAM 来获得访问 BLOB 数据的可能和更大的存储灵活性。

(P076)

除非要考虑可扩展性和安全性，不然可把数据访问层和业务逻辑层放在相同的物理层中来以提升应用程序的性能。

【第09章】 【服务层指导原则】

(P081)

若是要经过服务提供应用程序功能的话，把服务功能分割为独立的服务层很重要。

在服务层中须要定义和实现服务接口和数据契约 (或消息类型) 。更重要的是要记住服务永远不该该暴露应用程序中内部的处理细节或使用的业务实体。

服务层应该提供翻译组件翻译业务层实体和数据契约之间的数据格式。

(P082)

服务把服务接口暴露给消息接收方。您能够把服务接口看做一个外观，它把应用程序内实现的业务逻辑 (通常是业务层中的逻辑) 暴露给潜在的消费者。

(P085)

幂等的端点确保了只会处理一个消息，重复的消息会被忽略。

(P086)

服务接口表示的是服务暴露的契约。契约定义了您的服务支持的操做以及这些操做相关的参数和数据传输对象。

对于服务接口的设计最大的错误就是把服务看成细粒度操做的组件。

(P087)

具象状态传输 (REST) 和 SOAP 表明了两种不一样的实现服务的风格。从技术角度来讲， REST 是一种架构模式，它使用简单的动词来构建，而且很适合 HTTP 。虽然 REST 架构原则能够应用到非 HTTP 的协议上，可是实践中 REST 实现一般和 HTTP 联合使用。 SOAP 是基于 XML 的消息协议，能够和任何通讯协议一块儿使用，包括 HTTP 。

(P089)

为了简单，可以使用 ASP.NET WEB 服务 (ASMX) ，可是必须有运行微软 Internet 信息服务 (IIS) 的服务器。

若是您须要诸如可靠会话、事务、活动跟踪、消息日志、性能计数器以及支持多种传输协议等高级特性的话，可考虑使用 WCF 服务。

若是您肯定为服务使用 WCF :

1. 若是您但愿和非 WCF 或非 Windows 客户端进行互操做，可考虑使用基于 SOAP 规范的 HTTP 传输；

2. 若是您但愿支持局域网内客户端，可考虑使用 TCP 协议和二进制消息编码以及传输安全和 Windows 验证；

3. 若是 WCF 客户端位于相同机器，可考虑使用命名管道协议和二进制消息编码；

【第10章】 【组件指导原则】

(P096)

应用程序的每一层都会包含一系列用于实现该层功能的组件。这些组件应该是高内聚松耦合的，以简化重用和维护。

【第11章】 【设计表现组件】

(P103)

UI 的需求取决于应用程序须要支持的功能及用户指望。

对于技术的选择有一个很重要的因素，那就是 UI 须要的功能。

(P104)

根据 UI 的需求，能够肯定应用程序的 UI 类型。有许多不一样的 UI 类型，每一种都有其优缺点。

富客户端移动应用程序能够支持离线的或间歇性的在线应用场景。而 Web 或瘦客户端移动应用程序只支持持续连续的应用场景。

富互联网应用程序 (RIA) 一般是具备丰富图形用户界面而且运行于浏览器中的 Web 应用程序。

若是应用程序的内容须要被 Web 搜索引擎搜索， Web 应用程序就很适合了。

基于控制台的应用程序提供了纯文字的用户体验，通常运行在诸如命令和窗口或 PowerShell 的命令行外壳中。它们最适合于管理或开发任务，不太可能做为分层应用程序设计的一部分。

在为 UI 组件肯定了 UI 类型以后，还必须选择合适的技术。

(P105)

WPF 应用程序经过分离 UI 和底层控制逻辑为 开发人员 / 设计人员 提供交互 —— 容许开发人员关注业务逻辑，而设计人员关注观感。

Silverlight 天生就支持异步 JavaScript 和 XML (AJAX) ，它在 Web 页面中经过 JavaScript 暴露其对象模型，可使用这项技术让 Web 页面组件和 Silverlight 应用程序进行交互。

(P106)

AJAX 是 .NET 框架 3.5 以及以后版本中 ASP.NET 的重头戏。

Silverlight 控件和包含控件的 Web 页面能够经过使用 JavaScript 来进行交互。

在为 UI 选择实现技术以后，下一步就是设计 UI 组件和表现逻辑组件。

UI 组件是一些给用户显示信息以及接受用户输入的视觉元素。在表现分离模式中，它们通常指视图。

(P107)

除非须要特殊的显示或特殊的数据集合，不然尽可能避免建立自定义控件。若是发现 UI 需求不能使用标准控件来实现，可考虑购买控件开发包而不是去本身写自定义控件。若是您必须建立自定义控件，尽量扩展既有控件而不是去建立新的控件。考虑经过附加控件的行为对控件进行扩展，而不是从控件继承，而且考虑为自定义控件实现设计器支持，让开发人员更容易使用。

表现逻辑组件处理用户界面的非可视化方面的问题。包括验证、响应用户行为、 UI 组件之间的通讯以及组织用户交互。

若是 UI 须要复杂的处理或必须和其余层进行通讯，可以使用表现逻辑组件来和 UI 组件的处理进行解耦。

表现模型组件以一种表现层中 UI 和表现逻辑组件可以使用的方式来表示业务层中的数据。

(P108)

表现模型组件应该尽量同时封装业务层中的数据以及业务逻辑和行为。

特定数据绑定技术可能须要数据源实现特定接口或事件来彻底支持数据绑定，好比 WPF 中的 INotifyPropertyChanged 或 Windows Forms 中的 IBindingList 。

【第12章】 【设计业务组件】

(P113)

设计业务组件是一项很重要的任务，若是没有能正确地设计您的业务组件，那么代码将变得难以维护和扩展。

(P114)

应用程序的总体设计和应用程序的类型决定了使用哪些业务组件来处理请求。

【第13章】 【设计业务实体】

(P119)

通常只在表现层须要或逻辑必须和基于 XML 的数据合做的时候才用 XML 。

要注意使用和操做 XML 会消耗大量的内存。

(P120)

微软 .NET 框架提供了能够把 XML 数据反序列化成对象及把对象序列化成 XML 的组件。

必须肯定如何跨边界传输业务实体。在大多数状况下，当跨诸如 AppDomain 、进程以及服务接口边界等物理边界传输数据时，您都必须进行数据序列化。甚至在跨逻辑边界传输数据时都要考虑进行序列化。

数据传输对象 (DTO) 是一种设计模式，它能够把多个数据结构打包成单个结构以进行跨边界传输。

(P121)

领域模型使用实体、值对象、聚合根、资源库以及领域服务进行表达，并将其组织成被称做界定的上下文 (bounded context) 的职责分块。

实体 —— 是领域模型中的对象，它们有惟一的标识而且在软件状态发生改变时不会改变。实体封装了状态和行为。

值对象 —— 是领域模型中的对象，用于描述领域驱动的某个方面。它没有惟一标识并且是不可变的。

聚合根 —— 是一种类型的实体，它把逻辑上相关的子实体或值对象分组在一块儿，并对它们进行访问控制以及协调它们之间交互关系。

资源库 —— 负责接收和保存聚合根，通常使用 对象 / 关系 (ORM) 映射框架。

领域服务 —— 表示操做、行为或业务过程，而且提供引用领域模型中其余对象的功能。有的时候，某个功能或领域的某个方面不能映射到任何具备特定生命周期或实体的对象中，这种类型的功能能够声明为领域服务。

【第14章】 【设计业务工做流】

(P123)

有三种基本的工做流风格 : 顺序、状态机以及数据驱动。对于顺序工做流，任务在指定的一组步骤内迁移，直到其完成。对于状态机工做流，活动被定义成一组状态和事件，事件会将活动由一个状态迁移到另外一个状态。对于数据驱动工做流，活动则根据数据相关的信息执行。所以，在设计工做流组件时，第一步是要理解您必须支持的工做流风格。

(P124)

你可使用代码、标记语言或代码和标记语言组合的方式来编写工做流。采用何种方式取决于您解决方案编写模式的需求。

WF 提供了以开发人员为中心的解决方案，用于建立顺序、状态机以及数据驱动工做流。它支持纯代码、代码分离及标记编写模式。

(P125)

BizTalk 支持顺序、状态机和数据驱动工做流，以及代码分离和标记编写模式。

(P126)

微软企业服务总线 (ESB) 工具包扩展了 BizTalk 的功能，它关注的是如何构建始终链接的、面向服务的应用程序。

【第15章】 【设计数据组件】

(P129)

数据层组件包含数据访问组件和服务代理组件，其中数据访问组件用于访问系统边界内承载数据，服务代理组件提供访问其后端系统经过 Web 服务暴露数据。

(P130)

数据层应该利用数据访问基础结构统筹全部的数据源链接。

(P131)

无论是加密仍是明文，都不要在数据库中保存用户密码以供从此验证。您应该是保存使用了盐值 (为哈希的值指定一个随机的字节) 哈希后的密码。

【第16章】 【质量特性】

(P135)

应用程序处理诸如可用性、性能、可靠性及安全性等质量特性的优劣程度反映了设计是否成功及软件应用程序的总体质量。

每一个系统对于每个质量特性的重视程度和优先级都不尽相同。

(P139)

延迟指的是响应任何事件以前的事件。

吞吐量指的是必定时间以内发生的事件数量。

应用程序的性能会直接影响其可伸缩性，而且缺少可伸缩性也会影响性能。

(P141)

可伸缩性是在不影响系统性能的状况下处理额外负载的能力，或是增长负载量的能力。有两种方式可提升可伸缩性 : 纵向伸缩 (向上扩展) 和 横向伸缩 (向外扩展) 。若是须要进行纵向伸缩，那么须要为单个机器增长诸如 CPU 、 内存及磁盘之类的资源。若是须要实现横向伸缩，那么须要为运行应用程序的农场增长更多机器来共享负载。

【第17章】 【横切关注点】

(P148)

在跨物理边界或进程边界的时候考虑使用基于消息的通讯，在进程内 (只跨越逻辑边界) 考虑使用基于对象的通讯。

消息队列能够进行事务性消息递送及支持可靠的只发一次的递送。

(P151)

应该尽可能让缓存的数据靠近使用缓存的地方，这样能够减小处理和网络往返过程，而且能够最大化性能和应用程序响应速度。

【第18章】 【通讯和消息】

(P161)

为组件解耦不只仅能够增进可维护性，并且能够提升灵活性，使得能够在未来更方便改变部署策略。

因为每一次跨逻辑或物理边界的通讯都会增长处理开销，所以须要经过减小往返和最小化在网络上传输的数据量等方式来设计高效的通讯。

(P162)

若是须要和其余系统进行互操做，则考虑使用 XML 序列化。可是要始终记住 XML 序列化会带来更多的性能开销。若是性能相当重要，那么能够考虑使用二级制序列化，由于它更快，而且序列化后的数据也比 XML 序列化后的数据更小。

(P165)

考虑使用 DTO 来做为数据传递的一个单元，而不是每一次都传递独立的数据类型。

【第19章】 【物理层和部署】

(P169)

对于非分布式部署，除了数据存储功能以外的全部的功能和层都在一个服务器中。

(P170)

对于分布式部署，应用程序的各层位于独立的物理层。这种分层机制将系统的基础结构组织成一组物理层的方式，经过这种方式能够针对特定运营需求和系统资源的使用状况对特定服务器环境进行分别优化。

您须要谨记 : 增长更多的物理层也就增长了复杂度、部署工做量和成本。

您能够利用异步调用、单向调用或消息队列等技术来减小跨物理边界调用时的阻塞。

(P171)

在设计分布式环境的时候，必须肯定哪些逻辑层和组件会放到哪个物理层中。大多数状况下，会把表现层放在客户端或 Web 服务器上；服务、业务和数据层放在应用服务器上；数据库则放在单独的服务器上。

肯定在分布式环境中如何部署组件时，能够考虑以下指导原则 :

1. 只在必要时将组件分布式部署。实现分布式部署的常见缘由包括安全策略、物理约束、共享业务逻辑和可伸缩性；

2. 若是表现组件须要同步使用业务组件，那么能够把业务组件和表现组件部署在相同的物理层中，以最大化性能及简化运营管理；

3. 若是出于安全性考虑，须要表现组件和业务组件之间具备信任边界，那么能够把它们部署在不一样的物理层中；

4. 除非出于安全性考虑，须要服务代理组件和调用服务代理的组件之间具备信任边界，不然能够考虑将它们放在同一个物理层中；

5. 尽量让异步调用的业务组件和工做流组件部署在相同的独立的物理层中；

6. 把业务实体和使用业务实体的组件放在相同物理层中；

(P172)

若是您正在开发一个须要访问应用服务器的客户端程序，或正在开发一个会访问独立数据库服务器的单机客户端程序，那么您能够考虑两层模式。

(P173)

对于三层设计，客户端会和部署在独立服务器上的应用软件进行交互，而应用服务器又会和位于另外一个服务器上的数据库进行交互。对于大多数 Web 应用程序服务来讲，这是最多见的部署模式，并且也能知足大多数通常的应用的须要。您可能会在客户端和 Web / App 层之间实现防火墙，在 Web / App 层和数据库之间又实现一道防火墙。

若是安全需求规定业务逻辑不能部署在边缘网络中，或是应用程序代码须要使用大量服务器资源，您但愿把相关功能的负载转移到其余服务器，那么您能够考虑四层模式。

若是出于安全方面的考虑，不能把业务逻辑放在前端 Web 服务器上，那么能够考虑为 Web 应用程序使用分布式部署。能够为业务层使用基于消息的接口，而且考虑使用二进制编码的 TCP 协议来和应用层进行通讯，以得到最佳性能。还应该考虑使用负载均衡来分发请求，这样可由不一样的 Web 服务器来处理请求，而且要考虑在设计可伸缩 Web 应用程序时避免服务器亲和性，为 Web 应用程序设计无状态的组件。

(P174)

对于 N 层部署，您能够把表现和业务逻辑放在客户端，或只把表现逻辑放在客户端。

“纵向扩展”就是升级正在运行的硬件，而“横向扩展”则是经过把应用程序分发到多个物理器上来分担负载。若是打算横向扩展，通常会使用负载均衡策略，即负载均衡集群。

(P175)

负载均衡经过把客户端的请求分发到多个服务器，扩展了基于服务器程序的性能，好比 Web 服务器。负载均衡技术通常指负载均衡器，接收请求，而后在必要时将其转发至某个主机。负载均衡主机并发响应不一样的客户端请求，即便多个请求来自相同客户端。

根据路由技术，负载均衡器可能会检测到无效的 Web 服务器，而后把它从路由列表中移除，这样能够将失败带来的影响降到最低。

若是每个客户端请求之间不须要进行跟踪也不须要保存信息，换句话说通讯是无状态的，那么负载均衡集群是最具伸缩性也是最有效率的。若是必须跟踪状态，那么可能须要使用亲和性技术和会话技术。

(P176)

在开发过程当中，若是使用 Internet 信息服务 (IIS) 6.0 或以上的版本，能够配置 IIS 为 Web 园模式，帮助确保开发的应用程序正确处理了会话状态。

Web 服务器、 Web 农场同样，若是业务层、数据层和表现层没有位于相同的物理层上，能够经过应用农场的方式来横向扩展业务层和数据层。将从表现层过来的请求分发到农场中的每一服务器上，都有差很少的负载。根据每一层的需求及指望用户个数的负载，应将业务层和数据层的组件放到不一样的应用农场中。

(P179)

通常状况下，若是打算扩展应用程序，能够从两种基本选择中选择一个或者两个进行组合，这就是“纵向扩展”(让盒子变得更大)和“横向扩展”(用更多的盒子)。

对于“横向扩展”，增长更多服务器而且使用负载均衡和集群的解决方案。除了能处理额外的负载，“横向扩展”应用场景还能缓解硬件故障的问题。

使用额外的处理器和增长内存的纵向扩展是一个经济实惠的解决方案。这种方案还能够避免引入“横向扩展”和使用 Web 农场和集群技术带来的额外成本。应该先考虑“纵向扩展”选项，而且经过性能测试来检查“纵向扩展”方案是否达到了制定的可伸缩性标准，以及是否在某种可接受的性能范围内能支持必要的并发用户数。

若是因为 CPU 、 I/O 或内存上的瓶颈，为解决方案进行“纵向扩展”不能提供足够伸缩性，那么必须进行“横向扩展”和引入额外的服务器。

(P180)

具备清晰远程接口的松耦合的分层设计，相比紧密耦合的混乱交互的设计，更容易进行“横向扩展”。因为分层设计天生就具备分离点，那么在层的边界进行“横向扩展”就很是适合了。其中的诀窍是找到正确的边界。

【第20章】 【选择应用程序类型】

(P187)

在选择应用程序类型的时候，您须要考虑需求、技术限制，以及最终的用户体验类型。

(P188)

每一个应用程序类型均可以使用一种或多种技术来实现。使用场景和技术限制，以及开发组的能力和经验都对技术的选择有影响。

(P191)

RIA 应用程序通常依赖于一个客户端的插件或一个托管的执行环境 (好比 XAML 运行时或 Silverlight) 。这个插件须要和远程的 Web 服务器进行通讯， Web 服务器能够生成客户端插件或执行环境所须要的代码和数据。

【第21章】 【设计 Web 应用程序】

(P196)

在设计一个 Web 应用程序时，考虑使用一些技术，好比缓存和输出缓冲来下降浏览器和 Web 服务器之间的来回通讯，以及 Web 服务器与其下游服务器之间的通讯。一个好的缓存策略多是一个很是重要的跟性能相关的设计要点。

(P198)

受权决定着一个已经经过认证的身份是否能够执行某个任务，以及是否能够访问某些资源。

您应该使用缓存来优化对引用数据的查找，避免网络往返通讯的开销，避免没必要要的及重复的提交。

(P200)

尽量地使用 CSS 来布局，而不要使用基于表格的布局。

基于表格的布局在渲染的时候会慢一些，而且在布局复杂的时候会出现一些问题。

将客户端脚本放在一个独立的脚本文件中，这样作能够被浏览器缓存。

(P201)

对于多服务器 (Web 场) 的场景，而且必须在服务器之间集中存储 Session 数据，那么考虑使用 SQL Server 状态存储。

【第22章】 【设计富客户端应用程序】

(P209)

富客户端的用户界面具备高性能、高交互性以及用户体验丰富的特色，并可适应独立的、连线的、偶尔可连线的以及离线的场景。

(P210)

在设计一个富客户端应用程序的时候，软件架构师的目标就是要选择一项合适的技术，而后经过将任务按不一样内容领域进行划分，使得设计出来的结构的复杂度最小。设计必需要在性能、安全、重用性以及易维护性上知足应用程序的需求。

(P215)

有时候，尽管应用程序的其余全部方面都表现得不错，但一个差的用户体验就能产生严重的负面影响。所以将您的应用程序设计成从一开始就提供一种引人注目并直观的用户体验是很是重要的，由于用户体验会被您的应用程序的架构的不少不一样方面所影响。

尽量利用数据绑定功能来显示数据，尤为对于表格式的数据和多行的数据。这样作能缩减所须要的代码，简化开发并减小代码错误。

(P218)

Windows 窗体、 WPF 和 Silverlight 数据绑定都支持双向绑定策略，它容许将数据结构绑定到一个用户界面组件上向用户显示当前的数据，并容许用户修改数据，而后使用用户所输入的值自动更新原来的数据。

【第23章】 【设计富 Internet 应用程序】

(P225)

RIA 在提供了 Web 应用程序在部署和维护性能上所拥有的大部分优势的同时，还支持丰富的图形和流媒体。

【第24章】 【设计移动应用程序】

(P241)

若是要构建富客户端，那么业务层和数据服务层可能会放在设备自身。若是要构建瘦客户端，全部的层都要放在服务器上。

【第25章】 【设计服务应用程序】

(P255)

“服务”是指能提供一组功能的公共接口。

【第26章】 【设计托管和云服务】

(P270)

基于云的服务一般分为几种类型，例如 存储/计算，业务服务以及 零售/批发 服务。

【第27章】 【设计 Office 业务应用程序】

(P287)

OBA 是一种企业整合应用程序。

OBA 在设计上是经过使用开放的标准、标准的文件格式和 Web 服务来进行协做。

【第28章】 【设计 SharePoint LOB 应用程序】

(P301)

SharePoint LOB 应用程序能够被配置成经过网站的形式来发布面向 Internet 的内容，这样网站就能够与 Web 场的部署一块儿向外扩展以支持大量用户的访问，它还能够与 ASP.NET 集成在一块儿，利用这些网站来显示 LOB 数据。**