《精通.NET企业项目开发》 - 书摘精要

(P7) 处于任何逻辑层面上的类，对于同一层面上的其他类应该是可重用的；对于在同等范围内其他所有需要该数据的类而言，提供数据的类应该是可以被调用的；

(P9) 大多数企业系统都是用平台无关的技术构建的；

(P16) 良好设计的代码必须能进行分解，能够划分为独立的功能块；

(P17) 企业开发通常要求很强的松散耦合度；

(P19) 松散耦合类的真正评价标准是要看针对它编写单元测试的能力；

(P21) 抽象接口是类型解除关联的流行方法，当试图对需要交互的类实现松散耦合时，就需要用到这种方法；

(P35)

在创建软件时，针对可维护性进行设计是最重要的目标之一；

不易改变的最大阻力来自于依赖 —— 即系统中依赖于其他类的那些类。依赖可能出现在代码的各个方面 —— 高层类可能依赖于低层类，反之亦然；

(P46) 灵活性测度的是改变代码的难易程度；

(P47) 重用性测度的是代码的可移植性，以及在软件的其他地方可以重用到什么程度；

(P63)

依赖倒置准则(Dependency Inversion Principle, DIP)就是将类从具体的实现中分离出来，让这些类仅依赖于抽象类或接口；

Robert C. Martin 这样定义 DIP :
(1) 高层模块不应该依赖于低层模块。两者都应该依赖于抽象；
(2) 抽象不应该依赖于细节。细节应该依赖于抽象；

应用 DIP 的第一步是针对每种低层依赖提取接口；

(P65)
依赖注入实现方式：
(1) 构造函数注入 —— 构造函数注入通常应用于重构的最后阶段，它是通过类的构造函数提供依赖的过程；
(2) 设置函数注入 —— 设置函数注入通过设置函数(Setter)属性将依赖模块注入高层模块的过程；
(3) 方法注入 —— 方法注入要求依赖实现一个接口，高层模块会在运行时引用和注入这个接口；

(P68) 设置函数注入方法可能不如构造函数注入那么显而易见，但是，如果在构造函数中需要注入大量的其他依赖，那么将可选的依赖移到基于设置函数的方法可能更加明智，因为这样可以使该类的结构更易于理解；

(P83) 在编写让测试可以通过的代码之前，要先让测试失败；

(P91) 首先要知道基本准则，知道自己正在干什么，然后才能走捷径以提高速度；

(P149)

控制反转是一般准则，依赖注入是该准则的实现；

IoC容器只是一个包含类型和实现的字典;

(P153) 将所有的开发时间都花费在基础结构关注点上并不能更快地构建应用程序；

(P157) 自动连接依赖是使用IoC容器所能获得的最大好处；

(P169) 中间件 —— 是连接软件组件或应用程序的计算机软件；

(P189) 应用程序的主要目的和我们作为开发人员存在的唯一目的就是解决业务问题；

(P190)

业务逻辑层中存在的3种主要模式：事务脚本(Transaction Script)、活动记录(Active Record)和领域模型(Domain Model)；

事务脚本是一种非常简单的业务设计模式，它遵循面向过程的开发方式，而不是面向对象的方法。它为每个业务事务创建一个过程，每个过程都包含完成业务事务所需的所有业务逻辑，包括工作流、业务规则和验证检查到在数据库中持久保存的所有内容；

(P191) 事务脚本模式的一个优点是，它非常简单，很易于理解，不需要任何关于该模式的前期知识就很容易明白它的作用。如果有新的业务用例需要处理，那么可以直接添加新方法来处理它，该方法将包含所有相关的业务逻辑；

(P192)

活动记录(Active Record)模式是一个非常流行的模式，当底层的数据库模型与您的业务模型相匹配时，这种模式尤其有效；

在活动记录模式中，每个业务对象都负责它自身的持久化和相关的业务逻辑；

(P194) 领域模型与活动记录模式之间的主要差异是，领域模型的业务实体存在于领域模型之中，它们不知道如何持久化自身，且数据模型和业务模型之间并不一定要存在一对一的映射关系；

(P198)

领域模型模式相比于事务脚本和活动记录模式的另一个优点是，因为领域模型不包含数据访问代码，所以可以容易地对其进行单元测试，而不必模拟和存根这类数据访问层的依赖；

领域模型最重要的一个强项就是处理复杂的业务逻辑，但是当应用程序中包含非常少的业务逻辑时，全面使用领域模型就有些使用过度；

(P200) 学习的最佳方式就是通过示例；

(P255)

数据访问层包括所有的CRUD(创建、读取、更新和删除)方法和查询机制，这使得业务逻辑层能够针对任何给定的条件检索对象；

数据访问层不应该包含任何业务逻辑，并且应该由业务逻辑层通过接口来访问数据访问层；通过接口进行通信能够轻易地替换数据访问层的实现，而不会对软件的合理性产生任何负面影响；

(P256) ORM的作用是在关系模型(数据库)和面向对象模型之间架起一座桥梁；

(P257) DataContext 类负责跟踪改变以及管理标识映射和并发关注点，它是所有进入数据库的入口点的管理器；

(P258) Linq To SQL 包含一个 DataContext 类，该类跟踪数据变化，并保持所有从数据库取出的对象的标识映射；

(P272) Entity Framework 的强大之处在于关系数据模型并不要求与业务模型存在一对一的映射；

(P273) Entity Framework 不仅仅限于数据库。在一个实体模型中可以从很多不同的数据源提取数据，包括对数据源使用服务；

(P288)

持久化透明(Persistence Ignorance)的思想是保持业务对象与数据访问层解除关联，这样业务对象就仅包含与业务逻辑相关的代码；

NHibernate 的一个最佳功能就是对持久化透明的支持 —— 这意味着业务对象不必继承任何基类或实现任何架构接口；

(P321) 对象关系映射器在数据库的关系数据模型与面向对象的领域模型之间架起了一座桥梁(更准确地讲是解决了不匹配问题)；

(P324)

MVC将应用程序的前端分解为3个概念层 —— 模型(Model)代表应用程序的数据，视图(View)代表UI中的可见组件，而控制器(Controller)则处理模型和视图之间的数据通信和业务规则；

MVC的首要任务是尽可能地将数据从UI中分离出来，通过这种分离，开发人员可以更加方便地修改UI或数据和业务规则，同时又不会相互影响；

(P336) 我们的目标不是将开发领域统一为一种全功能的设计，我们的目标是建立应用程序，使它足够安全、可测试和灵活以适应功能的伸缩和增长；

(P340) MVP模式的核心在于模型，或者更准确地讲，在于代码的逻辑部分，这些部分处理业务规则和逻辑；

(P341)

在大多数情况下，表示器是作为对视图进行的一种可测试抽象；

ASP.NET页面的视图或UI部分是将信息提交到Web服务器或从Web服务器获取信息的主要入口点；

(P348) 表示器的目的是处理到视图的输入和来自视图的输出；

(P370) 表单是由动作和方法组成的；

(P371) Web MVC 将到达的请求与特定的输出进行了分离，将该请求路由至服务器端对象上的对应方法；

(P377) 系统中的每个概念实体通常都是由一个模型、一个控制器和n个视图组成；

(P380) Web MVC 的威力体现在它能够将正确的体系结构模式与快速应用程序开发相结合；

(P383) ASP.NET MVC 视图都有一个名为 Model 的引用，该引用是用作该页面所引用的模型对象的一个句柄；

(P394) 在领域驱动设计(Domain Driven Design)领域中，认识域模型对象的规则及其判断是否违背了这些规则通常都属于域模型对象本身的职责；