《Microsoft .NET 企业级应用架构设计》 - 学习笔记

**《Microsoft .NET 企业级应用架构设计》

========== ========== ==========
[做者] (意) Dino Esposito (意) Andrea Saltarello
[译者] (中) 陈黎夫
[出版] 人民邮电出版社
[版次] 2010年06月 第1版
[印次] 2010年06月 第1次 印刷
[订价] 69.00元
========== ========== ==========

【前言】

(P001)

每次遇到软件项目时，咱们都会建立一个解决方案。这个过程就叫作架构设计，而架构设计的最终产物就是软件架构。

架构是一个系统中最为核心的部分，是构造系统过程当中的支柱。

【第01章】 【当代的架构师和架构】

(P003)

在软件领域中，架构就是指为客户构建系统。

(P004)

优秀的架构师是团队所必需的。那么什么是优秀呢？这我的必须有丰富的经验、良好的教育以及相应的资格。

当代系统须要不少的工程以及理解，但不须要太多艺术和主观的猜想，这正是优秀架构师应当努力的方向。

(P007)

描述架构的一种很是流行的方法是使用 UML 图表。

(P009)

架构将被精炼到真正重要的事情上 —— 不管这事情是什么。

(P010)

领域驱动设计理论实际上建议老是使用工厂来建立复杂的对象。

通常来讲，使用 virtual 或 sealed 修饰符须要承担很多的责任。

(P015)

架构设计要基于对需求的分析，分析会决定系统将要作什么，而架构则决定系统如何作。

(P017)

架构师最终将负责系统的开发，并与开发者团队协调，技术详细说明书正是架构师和开发者沟通并传达架构的工具。

沟通是架构师的关键。架构师须要与开发者沟通，也须要与项目经理和分析师沟通，或许还要与用户沟通。架构师很重要的一个技能就是语言要明确清晰。

(P018)

架构师不过就是一个优秀一些，更有经验的开发者而已。

(P019)

一般而言，分析应属于项目领域中的专家，而架构师无需如此。分析师能够告诉架构师他对系统的理解，包括系统如何工做以及系统须要作什么等。

(P020)

架构师和开发者之间的区别就在于经验和教育经历。

【第02章】 【UML 必要知识】

(P028)

UML 基于一系列的图形化标记，特别适合在面向对象场景中建模。

(P029)

建模对于任何软件项目来讲都是个核心步骤，对于大型的企业级应用程序 (特别是那些支撑公司正常运做的程序) 来讲，其做用更加不容忽视。

在软件领域中，模型应该与建筑中的导航图、计划图和物理模型同样重要 —— 这是必须而不是可选的。

【第03章】 【设计原则和模式】

(P056)

一个设计精良的系统并非一系列指令和修补的堆砌，里面还有不少与设计直接或间接相关的东西。

一个良好的代码体系能够容易地找到 Bug 所在，也能够轻易地修复 Bug ，还能够在任什么时候候进行任何程度的改进，包括可扩展性和可伸缩性。考虑到这些，可维护性就成为了设计系统时最应该关注的问题。

(P060)

高内聚的模块意味着高的可维护性和可重用性，由于这些模块的外部依赖不多。

(P061)

模块之间显然须要通讯，不过通讯应该依赖于一系列设计良好且不易改变的接口。

低耦合和高内聚唇齿相依。若系统知足了这两个条件，那么一般来讲该系统已经基本知足了高可读性、高可维护性、易于测试和易于重用的要求。

分离关注点的核心在于将系统拆分红各不相同且最好没有重叠的功能。每一个系统中的功能都表示了一个关注点，即系统的一个方面。

(P062)

分离关注点是经过模块化代码以及大量运用信息隐藏来实现的。

(P063)

在过程式编程中，分离关注点是依靠函数和过程来实现的。

(P065)

面向对象设计的基本原则能够总结成 3 条 : 找到合适的对象、尽可能下降耦合和尽可能保证代码重用。

(P068)

基于接口，而不是实现编程。

(P070)

尽可能使用对象组合，而不是类型继承。

(P072)

模块应该对扩展开放，但对修改关闭。

(P074)

开放 / 封闭 原则和里氏替换原则有着紧密的关系。任何使用了某个违反里氏替换原则的类型的方法都没法知足 开放 / 封闭 原则。

(P076)

高层次组件不该该依赖于低层次组件，两者均应依赖于接口。抽象不该该依赖于细节，细节应该依赖于抽象。

(P080)

使用设计模式在本质上并不能让你的解决方案更有价值，真正的价值在于，在交付的时候你的解决方案是否能正常工做并知足需求。

(P084)

惯用法是一个硬式编码在编程语言或实如今 框架 / 技术 中的模式。

惯用法是一种充分利用语言能力，并从代码中获取期待的行为的作法。

(P086)

推荐在公开签名中使用 IList<T> 或其派生接口，或者使用实现了 IList<T> 接口的自定义类型。

(P088)

全部的 IoC 框架都基于一个容器对象构造，这个容器对象将和一些配置信息绑定，并解析依赖。调用者代码将实例化容器，并将须要的接口以参数的形式传入。做为响应， IoC / DI 框架将返回一个实现了该接口的具体对象。

【第04章】 【业务层】

(P121)

业务层是全部分层系统的核心，包含了系统的核心逻辑。

(P123)

业务逻辑层处于分层系统的中间位置，负责表现层和数据访问层之间的信息交换。

不少时候，架构师更倾向于使用数据迁移对象 (Data-Transfer Object , DTO) 在层之间交换数据。

业务对象同时包含了数据和行为，是一个能够参与到领域逻辑中的完整对象。

数据迁移对象更像是一种值对象 —— 即一系列数据的容器而没有相关的行为。

为了序列化，业务对象中的数据会复制到数据迁移对象中。

数据迁移对象仅仅是所须要部分数据的投影而已。

(P125)

工做流与普通类型的不一样之处在于，它容许经过逻辑上的图表来表达任意的逻辑。

(P126)

对于 Tier ，咱们用其表示系统中的物理上的硬件和软件，由执行一样功能的一台或多台服务器定义。相反地， Layer 用来表示系统中完成指定任务的逻辑部分。

Layer 通常用来组织代码，而 Tier 则是指代码运行的位置。

多个 Layer 能够共存于同一个物理 Tier 上。同时，某个 Layer 也应该能够轻易地移动到另外一个 Tier 上。

每一个层都有能够看作是一个黑盒，这个黑盒对输入和输出有着定义清晰的契约 (接口) ，且没有或不多依赖于其余层以及物理服务层。

分层带来的好处主要是条理清晰，且有利于重用以及分离关注点。

分离关注点建议层应该有良好的封装，或者说高内聚低耦合。

良好的可重用性加上正确地对功能进行拆分将大大下降系统的维护成本。

(P127)

物理层中一个重要的概念是，一个层就表示一个须要穿过的边界，这个边界多是进程边界或计算机边界。穿过边界是个代价很高的操做，若须要到达远程计算机，那么代价要比到达同一台计算机中不一样的进程高。一个估算比例是穿越进程边界要比进程内部调用慢 100 倍左右。若须要经过网络访问，还要更慢一些。

咱们应该尽量地下降物理层的数目。添加一个新的物理层以前，必需要通过仔细的成本收益分析，这样作的代价大多在于增长了复杂性，而优点通常体如今安全性、可伸缩性以及容错性上。

(P128)

远程使用的业务逻辑层必需要由一个粗粒度的接口封装起来 —— 通常使用门面 (Facade) 模式。

对于那些不是一直在线的应用程序来讲，将业务逻辑层部署到客户端是必须的。

业务逻辑层不该该看作是一个总体的组件，或者一些不相关模块的组合。多年的实际经验告诉咱们，业务逻辑在其余层 (指经典的 3 层架构) 中的适当重复是能够接受的，也是不少现实程序的作法。不过这种作法有必定的限度，且不该该受到鼓励。

(P129)

分散在表现层和数据访问层中的逻辑有可能只是出于性能方面的考虑才进行的重复。

(P130)

数据访问层须要了解的仅仅是如何获取记录，须要检查的是数据类型以及可控性，须要确保的是数据完整性和索引。

你应该仅仅把存储过程当作一个数据库工具，而不是做为业务逻辑的表达工具。

(P132)

历史上，事务脚本是第一个被普遍应用的业务逻辑模式。若干年后，另外一种基于表数据的模式逐渐浮出水面，名为表模块 (Table Module) 。表模块的设计角度还是一系列事务，不过事务是按照数据分组的。

最简单的对象模型看上去就像是数据库表的数据模型，这里组成模型的对象就是数据库中的记录，并加了一些额外的方法。这个模式一般叫作活动记录 (Active Record) 。

(P133)

领域驱动的设计必定会使数据模型和领域模型之间存在着不小的差别。这个模式一般叫作领域模型 (Domain Model) 。

总而言之，若你感受更应该关注于操做，能够选择事务脚本模式。若以数据表的形式考虑更方便，那么选择表模块模式。若领域模型与数据模型很是类似，那么活动记录模式可能更适合使用。而若建模的过程须要从各个相关对象开始，并划分红众多子系统，则能够选择领域模型模式。

(P134)

一旦你对领域模型模式有了足够的了解，不管系统的复杂性如何，你均可以使用领域模型模式。

过程式模式在达到某种程度以后，其添加功能带来的复杂性会以指数方式增加。

(P135)

事务脚本 (Transcation Script) 模式多是业务逻辑层中最简单的模式了，它是一个纯粹的过程式模式。

事务脚本模式鼓励你放弃全部的面向对象设计，将业务组件直接映射到须要的用户操做上。

(P136)

事务脚本适合应用于那些业务逻辑很是简明直白，且最好不大可能改变的简单场景中。

简单是事务脚本最值得一提的优点，它没有开始时的额外代价，且能够和快速应用程序开发 (Rapid Application Development, RAD) 环境良好地配合。

对于逻辑很少、时间紧迫且依赖于强大的集成化开发环境 (如 Visual Studio) 的项目，事务脚本是其理想的选择。

(P146)

若系统中的表现层和数据访问层都是基于表状数据结构，那么表模式将是很是好的选择。

(P151)

DataSet 的核心功能是一个数据容器，专门用来管理表格状数据，其中的名词也使用了表、列和行等相似数据库的概念。DataSet 并不了解为其提供数据的对象，且 DataSet 可被序列化。

DataSet 要配合其余数据表相关的对象 (例如， DataTable 、 DataRow 和 DataRelation ) 工做。 DataSet 中包含了一系列数据表的集合以及这些表之间的关系，而 DataTable 中则包含了一个数据行的集合，以及相关的约束和索引信息。

(P157)

活动记录 (Active Record , AR) 是一种应用于相对简单的领域模型，但仍旧基于对象的模式。

活动记录基于数据表中的行，而不像表模块那样基于数据表。

活动记录对数据有行级别的粒度，而表模块关注的是整个数据表。

活动记录就是指一个封装了数据库表或视图的一行的对象，对象中能够同时包含数据 (列中的值) 和行为 (包含逻辑的方法) 。

活动记录对象中一般会包含用来执行经常使用查询的查找方法、 CRUD 操做、验证以及领域相关的计算和检查功能。

(P158)

活动记录很是适合于不少的 Web 站点，由于不管其中涉及多少个数据表，其业务实体和关系型数据表的结构大多比较相似。

(P167)

在设计领域逻辑时，若选用了过程式方法或活动记录模式，那么实际上采起的是以数据为核心的作法。

在数据为核心的方法中，咱们通常从数据库开始设计，随后根据所须要的操做 (最终会操做数据库) 或数据表进行业务组件的建模。

(P168)

领域驱动设计实际上是一种考虑问题的方法 —— 一种将问题领域放在全部事情中首要位置的方法。

(P169)

领域模型能够看作是活动记录的“大哥”。领域模型彻底与数据库独立，是一个尽量贴近真实流程的模型，而不是去贴近架构师但愿的流程。

(P180)

仓储模式在领域模型和数据访问代码之间添加了另外一个抽象的类。

【第05章】 【服务层】

(P186)

服务层能够看作是表现层结束、业务逻辑层开始的一个边界，服务层用来尽量地下降表现层和业务逻辑之间的耦合，让表现层无需关注业务逻辑层中的具体实现组织方式。

(P188)

服务层位于系统中的两个互相通讯的逻辑层之间，使两个层可以在松散耦合并优美地彼此分离开的同时，仍旧能够完美地彼此通讯。

服务层将组织业务逻辑层中的组件 —— 包括服务、工做流和领域模型中的对象，并根据须要调用数据访问层。

业务逻辑层中惟一须要彻底和数据库细节分离的部分就是领域模型。

服务层是表现层和其余层之间的边界，理论上服务层应该经过数据迁移对象与表现层交互，并在内部根据须要将其转换成领域模型类。服务层中暴露的每一个方法都组织使用到其余服务，包括工做流，以及经过数据映射器或 对象 / 关系映射器 (Object / Relational Mapper, O/RM) 支持的语言执行数据库操做。

(P189)

服务层从表现层中获得输入，并组织工做流、服务和数据访问组件。

一般来讲，服务层就是一系列暴露了逻辑上相关方法的类，供其余层 (一般是表现层) 调用。

(P191)

在设计应用程序时，面向服务容许使用独立的组件并同时提供固定的公开接口，这些组件能够随时被替换，只要与其余组件的契约不变，就不会影响到系统的功能。

(P192)

从架构上讲，服务层应用了软件设计中一个通用且人人皆知的原则 —— 低耦合，可能还应用了另外一个原则 —— 高内聚，这是经过一个中间层解除用户界面和中间层的耦合来实现的。

服务层中的服务将被表现层直接调用，在 Web 前端中，也就是页面的代码后置 (Code-behind) 类将调用服务层。

(P193)

MVP 模式的实现能确保在 Windows 窗体或 Web 页面加载以后能够当即获得一个展现器对象，这一般使用依赖注入实现。

(P195)

服务层为用户界面和中间层提供了一个统一的契约，所以中间层便可专一于实现应用逻辑 (Application Logic) 。

(P198)

服务层添加了额外的抽象并除去了两个交互层之间的耦合，若这一点在你的系统中比较重要，那么应该建立服务层。服务层能够帮助你实现一个粗粒度的远程接口，并下降表现层与业务层之间的通讯流量。

(P199)

若你对 .NET Framework 有所了解，那么应该知道建立服务 (WCF 或 Web 服务) 就是个普通的类加上一些特性修饰而已。

服务归根到底就是一个附加了一些东西的类。

(P203)

服务层是经过一系列的 (服务) 类集合来把方法暴露给用户界面的。

(P236)

若想在浏览器中的页面里调用 Web 或 WCF 服务，必须使用一个代理类。该代理类就是一个 JavaScript 类，将在访问某个特定的 URL 时由服务的运行时生成。

(P237)

JSON 是一个新的标准，用于以脚本方式发出请求时浏览器和 Web 服务器之间经过 HTTP 交换数据。 JSON 优于 XML 的最主要缘由能够总结为 JSON 要比发展成熟的 XML 更加简单，且在全部支持 JavaScript 的浏览器中都有免费的内建反序列化引擎。

【第06章】 【数据访问层】

(P244)

数据访问层是系统中惟一知道并使用链接字符串和数据表名称的地方。

(P245)

数据访问层将对象模型保存至数据库中，并根据数据库中的数据建立类型实例。

(P246)

数据访问层是系统中惟一能够操做数据库的一层，系统的其余部分也不该该包含任何有关数据库的信息。

(P248)

仓储是一个用来放置对指定对象进行经常使用查询的类。

(P256)

面向数据访问层接口编程，而不是面向数据访问层实现。

(P266)

微软的 Unity Application Block (简称 Unity) 就是一个轻量级的依赖注入容器，支持构造函数、属性和方法调用的注入， Unity 随 Enterprise Library 4.0 一块儿发布。

(P271)

若需求不容许你使用商业或免费的 O/RM ，也必需要手工建立数据访问层。

(P334)

NHibernate 彻底支持 POCO 对象，而 LINQ-to-SQL 和 EF 则没法作到。

【第07章】 【表现层】

(P345)

表现层由两个主要组件组成 : 用户界面和表现层逻辑 (也叫作 UI 逻辑) 。

表现层逻辑将负责中间层和 UI 之间数据流的交互。

(P346)

表现层的职责应该从更高的角度考虑，即不依赖于物理 UI 、较高可测试性和不依赖于数据模型。

一个设计良好的表现层会让开发者在开发周期中更容易地切换到不一样的 UI 。

(P349)

架构师的主要职责是保证产品知足了全部的重要质量特质 (特别是可用性和可访问性) 。

表现层逻辑的最终目标是确保视图中的数据能够正确地 流入 / 流出 。

(P351)

自治视图目前已经再也不流行，最主要的缘由就是它难以测试。

咱们并非生活在完美的世界中，这也就意味着与理想状况相比，咱们须要更多的让步。

(P352)

在设计系统的表现层时，有一个基本的原则须要遵照，那就是让表现层和程序其余部分彻底分离，包括业务层和数据访问层。

(P356)

MVP 更加适合于大型、复杂的应用程序。

(P358)

视图的另外一个关键职责是呈现。

(P369)

无论怎样， MVP 并不建议应用于任意的程序上。

(P373)

对于那些须要支持多个 GUI 的场景，可能惟一的选择就是 MVP 模式了。 MVP 模式提供了一个最佳的可测试性、分离关注点、维护性和代码重用的组合。**