企业应用架构读书笔记与总结 狼

一、第一到四章主要讲述了，分层架构思想，数据关系映射，基本的数据架构图提出的基本思想。

二、第五章对后面章节的内容着了铺垫并发、事务、锁（如悲观离线锁、乐观离线锁） 、ACID原则等的基础内容。

三、第六章为后面的第十六章会话状态做铺垫性描述。

四、第七章讲述了分布式基础，为后面的分布式做基础描述，提出了尽可能避免过度设计、过度使用分布式，能单机解决的问题绝不使用分布式方案。因为跨进程的访问是很消耗资源的。提出了分布对象设计第一定律：不要分布使用对象。而且要紧可能小范围内使用分布对象，尽可能的发挥集群系能（通常总会需要对象分布到不同的进程中）。其提出在同平台下优先使用平台自己提供的远程调用机制，然后才是使用webserivce的方式。

五、第八章讲述了领域模型的基础提出了：脚本事务模型、表模型、领域模型，脚本事务模型注意依赖一直接书写sql等脚本来解决业务问题，其对于简单的应用比较合适，成本比较低廉。而表模型，主要是依赖于平台提供的dataset 、datetable等来直接进行数据的逻辑运算、对于规模不大的应用比较方便快捷在这一块.NET做的相当的方便。而领域模型主要是把所有的运算都以对象的形式来进行运算，在.NET种我认为是把数据库的值映射到类中，用类来进行逻辑运算，大量的使用了面向对象的思想来进行编程此模式对规模不大的运用成本太高，对比较复杂的和规模逐渐变大的系统后面的成本会逐渐的比其他2种模式的成本更低。而实际的运用中不可能只是其中一种模式在系统中运用，而是可能多种模式在系统中并存使用。对于本章当时自己为了了解几种模式的区别和能在一个系统中找出这几种模式，我也花了较长的时间去理解。

六、至此前面一致八章是第一部分，主要的是为第二部分着基础内容铺垫，使读者能有一个平滑的过程理解本书。 所有有的问题在第一致第五描述清楚的在后面将不再描述。

七、 第九章深入介绍事务脚本、领域模型、表模型，详细内如如第五。其增加了一个服务层的描述，主要思想是把内部业务逻辑进行封装（封装方式是3种模式）对外提供一个初粒度或者细粒度的访问接口（是对物业逻辑封装的方法，并不一定是个真实的接口）。

八、第十章讲述了表数据入口、行数据入口、活动记录、数据映射器。

1. 表数据入口：从数据库中取数据是取出全部数据，在dateset、datetable之间是有过滤器来选取其中的某条数据、update、insert也是基于dataset、datetable、等ADO.NET的几大对象的数据更新方式，如直接使用适配器的update方法等。其基本思想是分2步取数据，第一步是取出数据库中的所有数据（select * from　table，注：没有where语句）。然后在利用datetable的过滤器或者筛选器(select 、filter)通过过滤条件（如用已知的ID来过滤）来选取其中的某条语句，就得到一条数据；其是表模式的使用体现
2. 表数据入口的优缺点：需要读取过大的数据在内存中，占有较大的内存空间，cup压力大。对于小数据，或者对数据的操作运算比较频繁的时候直接在内存中运算比每次都去数据库中读取数据速度快。其对update的操作也不方便。还有可能存在数据实时性稍低的情况，比较读取数据到dataset等中取运算不能实时读取数据库中最新的数据。
3. 行数据入口：从数据库查询数据时，直接带有如“select * from  table where id=参数”的方式直接从数据库中选取具体的某行数据。他对数据的操作完全是基于数据库的，而不像表数据入口是居然ADO.NET对象的。Update 、delete的操作也是携带了where 条件直接对数据库的数据进行操作。其是脚本事务模式的体现。
4. 行数据入口的优缺点：直接对数据库选取的数据比较精确，但是当需要较多关于数据库的数据读取时，对数据库的操作过多，可能带来数据库压力比较大。对类似的数据需要多次的进行读取时，对性能有一定影响。
5. 活动记录：对数据库中的数据进行，通过数据映射后形成对象，然后相关的逻辑运算都在对象中进行，其必须依赖于数据映射。必须把数据库对象数据转换为类对象。对所有的插入操作、更新操作、删除操作、查询操作所需要的数据都是以对象的形式进行传输，如果是数据集在NET中可以利用泛型等来进行数据集的操作来进行对象间的数据传输；其是领域模型的使用体现。
6. 活动记录优缺点：必须依赖于数据映射，并且其效率在大部分情况下低于另外2种。并且其的代码量比另外2种更多，需要建立比较多的运算对象（类）。但是其在代码的编写过程中比较方便，而且如果需求变更时，对代码的改动量、和维护来说在大型系统中比较有优势。
7. 数据映射：把数据库的数据映射到实体对象中去。方便运算过程中直接使用。而不是需要对象数据时使用sql脚本去取数据。现在出现的大量的ORM就是这个东西如EF，linq to sql等都是这写东西。他省去了开发人员不懂数据库语言时的方便，只需多拽就可以实现从数据库中读取数据并且映射成类。但是其性能有一定的缺陷，但是现在已经做的很好了，在中小型系统中使用是完全可以接受的。

九、第十一章讲述了工作单元、标识映射、延迟加载方面的内容。

1. 工作单元：基本思想是把一组相关的操作封装在一个方法中，实现一次性提交，其需要的基础数据在更早时准备好，存在在特别设计的数组中，到提交方法时只需要提交即可。提交方法中包含有3个方法，一个方法是插入数据，一个更新插入进去的脏数据、然后是删除新插入的数据。这种模式如数据库中的事务是一个道理一样。但是我们可以把他的思想引入到代码。
2. 标识映射：把已经获取到的数据插入一个临时变量中或者缓存中，当要获取该对象时优先通过ID等标识从临时变量或者缓存中获取，如果获取不到在到数据库中查询在缓存。
3. 延迟加载：在数据运算时只携带运算相关的键（如ID），当计算需要跟多数据时在通过该键(ID)去数据库中(或者某个存储对象中)读取出对象的全部数据，实现一种延迟加载的方式。重影，键（携带一个或者多个真是数据）是真实数据的一个重影。使用方式有：虚代理、值保持器（类似标识映射的方式）、重影。如果延迟加载加载了多余的数据，时叫做波动加载。

十、第十二章讲述了标识域、外键映射、关联表映射、依赖映射、嵌入值、序列化LOB、单表继承、类表继承、具体表继承、继承映射器。

1. 标识域：其实就是通常说的主键一类的东西，用于在内存中和数据库对象管理起来，给表中的某行一个主键、然后内存中也有一个主键，然后通过主键即可以找带数据对象。该键可以是自增涨ID或者GUID或者身份证号之类的唯一值。同时又有表键唯一和数据库键唯一。表键唯一是在一张表中唯一的一个值；而数据库键唯一是指该键值在整个数据库中是一个唯一值。
2. 组合键：使用多个键值作为主键，只有多个键值在一起使才可以确定一个唯一的行。
3. 外键映射：把表A中存储了表A本身的主键同时其还存储了表B的主键，及通过表A存储了表B的一个主键值就可以找到表B中和表A关联的数据行了。
4. 关联表映射：在表A和表B之间增加一个表C存储表A的主键和表B的主键关联形成一行，就实现了A表通过 C表就可以找到B表关联的数据；此方法通常是在表A和表B已经存在并且修改表A或者表B时代价太大而是要的一种第3方表的形式。不足：大量的关联查询损耗性能。
5. 依赖映射：基本思想是在数据库持久化时，数据库中的某个类（依赖者）依赖于其他的类（所有者）。每个依赖者有且只有一个所有者。比如A表有列a.c而B表有多行a.c的值与A表的a.c相同；类似于一个目录下有多个文件一样的结构。
6. 嵌入值：把数据库中的某些字段的值用在类的实例化时，该类通过自身的一些计算拥有了一些拥有展示的值，形成一个实例类。而该类的值（除了从数据库中读取的），可以通过计算得来，如果把这些值直接存储在数据库中则可以提高效率（直接查询，而不需要运算）。
7. 序列化LOB：把一个对象直接序列化成字符串(json、二进制)或者xml后直接存储在数据库中。有json、二进制序列化和xml序列化，这个方式会导致如果类修改了，可能使早期存储的数据不能反序列化回来，导致数据丢失。并且数据是人眼很难看懂的必须通过程序反序列化后才看得明白。如果序列化的对象被多处拷贝以后，当想要修改其中的某个值是必须把所有的拷贝对象都拿出了执行并且修改。将是一个很痛苦的过程。
8. 单表继承：如有A、B、C 这3个类继承关系是A:B:C即C继承B，B继承A。则会有不同的建表的方式，而单表继承是把A、B、C所有的字段都建立在一个表中，所有的数据都存储在一个表中。这3个类随便怎么调整继承关系度不必修改表（新增字段除外），不需要连接表操作、可能是A类中没有的字段在表中也有数据列对应，比较多余，浪费数据空间。
9. 类表继承：同意是ABC这3个表分别为他们3个类建立3个表即A表、B表、C表，当调整3个类的继承关系时不必修改表，清新的类，没有浪费空间，但是其有多表连接操作，导致性能问题。如字段从A类移动到B类则必须同时修改表，实现对应。
10. 具体表继承：即给A类的字段建立一个表，而B类继承了A类，则B表的字段必须包含A表的字段和其自身的字段，C类继承了B类，所有C类对应的C表必须包含A类的字段、B类的字段和C类本身的字段。优缺点每个表都是自包含的，并且没有不相关的域，读取数据时不需要连接操作、只有类被访问的时候表才会被读取，分散负载。其处理主键比麻烦、不能把数据库映射关系抽象到类中、类中的字段修改位置改动比较大，如C类自己的字段如果调整到B类中择需要调子C表和B表，比较麻烦、超类上的一次查找需要检查所有的表，导致多处访问数据库，或者特殊操作，查找A类中的一个信息可能要查询A、B、C这3个表，或者比较特殊的查询操作。
11. 继承映射器：即在抽象类或者接口中定义基本的数据读取规则，而在实现类中去实现查找，去实现类属性和数据库字段的关联。

十一、第十三章讲述了元数据映射、查询对象、资源库。

1. 元数据映射：本身提出了代码生成和反射程序2种方法；反射是通过映射生成可执行的代码程序，如NET中的反射。反射调试困难，代码执行速度慢，但其具有很高的灵活性，可以动态选择程序的执行，可以把元数据保持到xml中等地方。NET的可以从dll中进行反射，并且NET的代码提示靠的也是元数据、其调试模式下生成pdb文件也属于元数据的一种方式，反射是当修改某部分代码时很难发现问题；而代码生成主要是输入元数据，输出映射实现的源代码。代码生成本人感觉是，想非强制类型语言（如js）可以动态构建、拼接js语句然后在执行拼接的js语句的一种方式。
2. 查询对象：是解释器模式在表示sql查询上的应用。客户端可以构造各式各样的sql语句，然后交有服务端去解释执行语句。服务端通过一定的领域模类构造出一些方便构造sql语句的方法，然后这些方法生成的语句叫由服务端去执行；比如linq to sql里面定义的一些方法，其实其本质也是解析构造出sql语句交由服务端执行生成。
3. 资源库：协调领域和数据映射层，利用类似于集合的接口来访问领域对象。其是定义对数据库访问的抽象类、或者接口；必须在子类中实现自己对数据库的查询具体对象接口、删除对象接口、增加对象的接口等。他定义了一个高层次的数据访问规则，有子类负责实现。由于其只是定义了高层接口，就不需要关心具体的数据源、高层接口负责业务的定义。

十二、第十四章讲述了MVC(常见的模式还有MVP、MVVM、PM)、页面控制器、前端控制器、模板视图、转换视图、两步视图、应用控制器。

1. MVC：视图充(V)当模型(M)的观察者、控制器(C)是视图（V）的策略；其本质就是观察者模式和策略模式的混合使用。
2. 页面控制器(MVP)：M:Model、V：View、P：Presenter;其原理是V修改了通过P传递给M，然后M修改后又通过P传递给V。
3. 前端控制器：对页面进行访问时，通常都要进行安全验证，安全验证是通用的，各个页面的逻辑和展现的东西却是不同的，所有在所有页面访问前都见上一个安全验证，使所有的验证逻辑都走相同的逻辑。在NET就如同HttpHandle一样，或者全局文件，的管道模式。
4. 模板视图：就是生成一个模板的HTML模板页，在需要修改内容的地方做标识，在运行网站的时候，把标识替换成网站需要的内容即可。
5. 转换视图：把一个页面需要的数据先保存在一个文档中，然后在对这个文档的数据进行转换成为html代码。 如我们需要的数据都在xml中，我们在用某种语言(XSLT是本书推荐的一种对于处理这种转换的最具有优势的语言)把这些xml转换为htmL代码。
6. 两步视图：第一步在动态页面中处理数据逻辑，然后最终代码会生成相应的html代码输出到客户端。我们假设在其第一次运行动态页面生成了最终的显示逻辑代码后即htmL代码，我们把生成的这些htmL代码截取保存起来。就把动态的页面转化为了静态页面，以后再访问的时候，就直接访问静态页面，而不需要走动态页面那么复杂的运算过程。其第一步是运行动态代码生成需要展现的逻辑，第二步是保存页面逻辑形成的html代码。
7. 应用控制器：决定运行那个领域逻辑和决定用那种视图来显示应答消息；如同MVC中的路由控制器一样。根据输入的命令来跳转到相应的视图逻辑中去。根据不同的命令来显示不同的视图。

十三、第十五章讲述了远程外观、数据传输对象

1. 远程外观：把需要的一组数据封装在一个粗粒度的方法中返回，其中粗粒度的方法调用了很多细粒度的方法。访问时提供一些基本信息，而返回时返回一组比较全面的信息，这些信息你每次运算可能只需要其中的一部分。如NET下webserivce就是一种比较好的远程外观。其实现了跨进程和分布式的数据访问，但其有性能损伤的问题；同时在这里还提到了会话外观，但本人对会话外观还未完全理解清楚。着重提供一组粗粒度的结果集，而不是细粒度的方法返回结果集。
2. 在远程外观中提到了服务层，其基本思想是把一些方法集封装成一个服务，供远程外观或者其他的调用。在服务器中不涉及具体逻辑，只是一个返回某项业务的服务。
3. 数据传输对象：在调用者之间传输数据的方式； 远程外观中粗粒度的结果集，必然导致不需要的数据在网络上传输，通常的方法是对对象进行序列化传输，有二进制数据传输、文本、json数据传输、基于（soap、wsdl协议的）序列化为xml的数据传输。数据传输必然存在服务端发送序列化后的数据客户端必须能解析服务端序列化后发回的数据，服务端和客户端对数据的封装必须能方向进行实例化回原来的对象。其关键是如何把对象序列化传输，客户端收到数据后如果解析数据的问题，通过什么方式进行数据的映射，序列化传输的数据映射为对象的问题。对于数据的序列化提出优先使用平台自身提供的序列化方式。

十四、第十六章讲述了乐观离线锁、悲观离线锁、粗粒度锁、隐含锁

1. 乐观离线锁：同时可以多个人编辑数据，对数据提交时冲突的地方进行合并出来类，类似于源代码管理工具TFS的思想；对出来事务时比较弱；其提交数据时进行版本管理，只有版本号一直的数据才能在相同的事务中提交。
2. 悲观离线锁，就是只能有一个人独占文件进行编辑，其他人不能改动，类似于源代码管理工具VSS的思想。悲观离线锁对处理事务比较有优势，并且其是乐观离线锁应用的补充。其有独占写锁，独占读锁、读写锁。
3. 粗粒度锁：就是对一堆的方法调用时把这一堆方法放到同一个锁里面。这一堆方法拥有同一个版本号，那么这一堆方法就共用了这一个锁，叫做共享锁，单锁有2类，所有有乐观共享锁和悲观共享锁。同时其产生了一堆方法(或者对象)，这堆方法拥有一个锁的控制对象，只有锁住这个对象就锁住了所有，这种就是跟对象锁
4. 隐含锁：在某些系统平台中某些方法方法提交了系统锁，或者在对一堆方法的调用时，其中的某个方法加了锁，而其他的方法没有锁，而我们调用的地方根本没有加锁的机会，而无意中产生了锁。

十五、第十七章讲述了客户端会话状态、服务器会话状态、数据库会话状态（注:此会话不是专指session，当然也包括session，而是在交互时需要的一些数据）

1. 客户端会话状态：把会话信息存储到客户端，如存储在Cookie、URL、隐藏域中，如果是复杂对象可以进行序列化后存储。数据存储在客户端不安全，可能存在数据丢失、数据量大时保持困难。
2. 服务器会话状态：把大量交互的数据存储在服务器内存中，而给客户端存储这些数据的一个标识(如NET的sessionid)，当需要这些数据时，客户端出示标识，就可以从服务器内存中读取数据。其容易导致服务器崩溃、集群处理比较困难、占用较大服务器内存。
3. 数据库会话状态：将会话的数据存储到数据库中，把会话数据存储在数据库中，给客户端一个标识（sessiondid），当需要数据时，用标识（sessionid）去数据库中查找数据。集群方便、但是对数据库性能有要去。讲会话数据存储在临时表或者会话信息存储到和业务一起的数据表中，然后加标识位区分会话数据。
4. .NET中对于session可以存储在IIS进程中，服务器内存中（可以是IIS服务器本身的内存中，也可以是另外一台服务器的内存中）、数据库中。

十六、第十八章讲述了入口、映射器、层超类型、分离接口、注册表、值对象、货币、特殊情况、插件、服务桩、记录集