《Microsoft .NET 企业级应用架构设计 (第2版)》 - 学习笔记

《Microsoft .NET 企业级应用架构设计 (第2版)》

========== ========== ==========
[做者] (意) Dino Esposito (意) Andrea Saltarello
[译者] (中) 李永伦
[出版] 人民邮电出版社
[版次] 2016年04月 第2版
[印次] 2018年05月 第5次 印刷
[订价] 69.00元
========== ========== ==========

【第01章】 【今天的架构师和架构】

(P010)

需求经由首席架构师处理以后会交由开发团队实现。

(P011)

瀑布模型已经是明日黄花，你能够将它的死亡归咎于软件开发是一种工程学。

软件开发最流行的敏捷方法学是极限编程 (XP) 。

(P012)

架构师参与开发流程的全部阶段，包括需求分析和架构设计、实现、测试、集成以及部署。

架构师的主要职责是 : 确认需求，把系统分解成更小的子系统，识别和评估技术，以及制定规范。

(P013)

架构师确认需求，尽力在设计里采用和知足它们。

(P014)

架构师须要具有的一个重要特征是语言清晰。

【第02章】 【为成功而设计】

(P020)

虽然 RAD 方案对于以数据为中心的小型简单应用程序 (如 CRUD 应用程序) 来讲可能恰好合适，但事实证实它对于包含大量常常改变的领域规则的大型应用程序来讲是一个危险的方案。

(P024)

团队就是让在技能上互补的人们互相合做。

(P026)

好的架构师都很清楚，只有写得好的代码，对软件原则和语言特性有很好的了解，恰当使用模式和实践，以及注重可测试性才能解决代码维护的问题。这使得编码比产生恰好能够工做的代码更加昂贵，但比维护和进化恰好能够工做的代码就廉价得多了。

(P027)

代码辅助工具不是魔法，它们所作的只是让你付出更低的代价和更少的努力就能够写出更好和更干净的代码。

【第03章】 【软件设计的原则】

(P039)

OOD 的基础能够总结成如下3点 : 找出相关对象、减小接口对象之间的耦合，以及善用代码重用。

(P053)

你不选择设计模式 : 最合适的设计模式一般会在你重构的过程当中浮现出来。

【第04章】 【编写优质软件】

(P061)

质量好的代码有一个基本的特色，那就是它必须是可测试的。

(P062)

代码异味会使代码变得愈来愈弱，找出并移除代码异味是重构的首要目标。

(P072)

领域层是最复杂的部分，也是最受需求波动影响的部分。所以，这个部分的缺陷最多。

(P079)

代码的质量经过 3 个参数来衡量 : 可测试性、可扩展性和可读性。

【第05章】 【发现领域架构】

(P083)

DDD 并不适合每一个项目，由于它对技能的要求很高，并且启动成本也很高。

(P085)

关键是机会和技能，关键是所针对的上下文。

(P094)

全部逻辑层实际上都部署到某个物理层，但不一样的逻辑层可能在不一样的物理层。

通常而言，咱们倾向于把整个应用程序栈部署到单个物理层，若是可能的话。

(P096)

应用程序层是分离表现层和领域层等接口层的绝佳方式。

应用程序层是系统后端的入口点，也是表现层和后端之间的链接点。应用程序层包含的方法几乎一一对应表现层的用例。

(P097)

应用程序负责实现应用程序的用例。它所作的就是编排任务，并把工做指派给这个栈下面的其余层。

(P098)

基础设施层的最突出组件是持久层，它就是一个传统的数据访问层，只是还可能覆盖普通关系型数据存储以外的一些数据源。持久层知道如何读取和保存数据。

【第06章】 【表现层】

(P102)

DTO 是一个类，用来携带跨越系统的逻辑层和物理层的相关数据。

用户体验不仅是可视化界面设计，而用户界面是用户体验的一部分，可能还是最重要的部分。

(P105)

理想状态下，每一个屏幕应该绑到一个视图模型类，它描述了用来填充视图的数据。此外，每一个屏幕应该绑到一个输入模型类，它描述了触发操做时将会离开屏幕的数据。

(P106)

MVVM 尤为适合具备强大双向数据绑定机制的应用程序场景。

就分层应用程序而言， MVC 、 MVP 和 MVVM 都是表现层的模式。

(P109)

若是 Web API 能够知足你的需求就用它，不然用 WCF 。

应用程序服务的类包含与用例一一对应的方法。

(P110)

应用程序服务能够访问这个栈下面的全部逻辑层和物理层。它能够查询和更新数据，若是有须要也能够调用外部 Web 服务。

(P113)

给网站添加一个面向设备的层是颇有必要的。

(P118)

SPA 首次向服务器请求只是为了获取一些初始的 HTML 。一旦用户界面加载完毕，应用程序也彻底初始化了，后续的交互就会经过 HTTP 请求上传和下载 JSON 数据来进行。

通常而言，若是你打算加入 SPA 大军，一般的缘由是你想充分挖掘客户端的潜能，得到一个更好的用户体验。

(P120)

SPA 相似于部署到 Web 上的桌面应用程序。

【第07章】 【神秘的业务层】

(P124)

TS 鼓励你跳过任何面向对象设计，把你的业务组件直接映射到所需的用户操做上。

(P127)

复杂性是采用领域模型模式的驱动力。

(P130)

在 ASP.NET MVC 应用程序里，任何用户界面操做最终都会转化成控制器的类上调用的方法。

(P134)

物理层的数量原则上应该尽量少。

(P136)

数据传输对象专门用来在不一样的物理层之间携带数据。

做为一个简单容器，使用 DTO 的缘由是它容许你打包多块数据，在单次往返里传输全部数据。

DTO 与生俱来就是可序列化对象。

(P138)

正确地作事的核心理念是效率 : 以优化的方式实现任务，快速且流畅。

作正确的事的核心理念是效益和达成目标。

【第08章】 【领域模型导论】

(P144)

领域层的目标和结构 : 领域模型、模块和领域服务。

DDD 模块就像 .NET 命名空间，用来组织类库项目里的类。

(P145)

值对象只是聚合在一块儿的数据；实体一般由数据和行为组成。

【第14章】 【持久层】

(P264)

持久层一般会建立成类库、被领域层 (特别是领域服务) 和应用程序层引用。持久层能够引用任何用于访问数据的技术，不论是 Entity Framework 或 NHibernate 等 对象 / 关系 映射 (O/RM) 、 ADO.NET 、 NoSQL 数据库，仍是外部数据服务。

(P271)

IQueryable 接口并不负责查询的实际执行。它所作的只是描述要执行的查询。执行查询和构建结果是 LINQ 提供者的任务。