《企业应用架构模式》（POEAA）读书笔记

原文地址： 《企业应用架构模式》（POEAA）读书笔记 做者： 邹齐龙(技术-5013

什么是架构

• Rolph Johnson认为：架构是一种主观上的东西，是专家级的项目开发人员对系统设计的一些可共享的理解
• 架构中包括一些决定，开发者但愿这些决定能尽早做出，由于在开发者看来它们是难以改变的。
•  若是你发现某些决定不像你想象中的那么难以改变，那么它就再也不与架构相关
• 理解： B/S (SmartClient、C/S) 架构， DotNet 架构， J2EE架构

企业应用的特色

1. 涉及到持久化数据
2. 不少人同时访问数据
3. 含有大量操做数据的用户界面
4. 与散布在企业内部或周围的其余的应用集成
5. 各类异构系统的概念含有不一致性
6. 业务逻辑一般是最没有逻辑的东西
7. 企业应用并不是都是大型的，但可能都为企业提供巨大的价值

  · 性能：不少时候，增长更多的服务器比增长更多的程序员便宜；若是增长服务器对性能的提高较大，则说明应用的伸缩性好 

· 分层：上层是用下层定义的各类服务，而下层对上层一无所知；分层的缺陷是不能封装全部的东西，所以可能带来级联更改，过多的层影响性能；Layer和Tier的区别是Tier可能更多的意味物理上的分离      

Brown分层模型

表现层>>控制层>>领域层>>数据映射层>>数据源层  

Core J2EE分层模型

客户层>>表现层>>业务层>>集成层>>资源层 

MS DNA分层模型

表现层>>业务逻辑层>>数据访问层 

Marinescu分层模型

表现层>>应用层>>服务层>>领域层>>持久层


· 领域模型：使用不一样职责的对象来联合解决业务问题，而不是经过事务脚原本处理数据 

· 阻抗不匹配：对象模型和关系型数据库之间的不匹配，一般经过对象-关系映射(ORM)解决 

· 软件事务的四个特性 

1.      原子性：要么所有成功，要么所有回滚

2.      一致性：事务开始和完成时，资源都不该该被破坏

3.      隔离性：事务成功完成以前，其影响不该该被看到

4.      持久性：事务不会由于任何崩溃而丢失更改 

· 事务的隔离级别（由高而低）

1.      可串行化：彻底隔离，并发执行的结果与以某种顺序依次执行的结果相同

2.      可重复读：容许幻读，更新者向集合中插入了一些元素而读的人只能看到其中一部分

3.      读已提交：容许不可重复读，全部已经提交的数据均可以读

4.      读未提交：容许脏读，容许读未提交的数据 

· 会话状态：无状态对象是一种不良设计；用无状态的服务器能够实现有状态的会话；若是有不少会话空闲，能够考虑用数据库存储会话；若是须要频繁访问会话，则应该使用服务器会话 

· 分布策略：分布对象的第必定律：不要使用分布对象；分布对象的第二定律：节约使用分布对象

领域逻辑模式分为 事物脚本、领域模型、表模块和服务层四种模式

　　不少设计者喜欢把业务逻辑分红两类：领域逻辑和应用逻辑，前者只与问题领域有关、然后者有时被称为工做流逻辑

1. 事务脚本

　　经过使用SQL语句或者存储过程返回记录集，记录集在系统的各层之间传递，在必要的时候能够经过更新记录集、使用SQL语句或者存储过程的方式更新数据库
　　事务脚本胜在简单，一般应用在小型的项目和系统中，但业务逻辑愈来愈复杂，使用这一模式就愈来愈难以保持良好设计，由于在程序里面充斥了大量的SQL语句和命令，一旦数据结构发生更改或者须要对系统进行修改，可能会出现许多难以发现的问题

2. 领域模型

　　领域模型是合并了行为和数据的领域的对象模型，领域模型建立了一张由互联对象组成的网，其中的每一个对象都表明着某个有意义的个体，可能大到一个公司或者小到订单的一行

　　简单领域可使用活动记录，即简单的单条数据记录和单个对象对应的模式，一个对象对应数据库中的一个表

　　复杂领域模型须要使用数据映射器，它可能使用继承、策略或者其余的设计模式，是一张由互联的细粒度对象组成的复杂网络，咱们常常会看到：多个类经过交互来完成很简单的任务

　　在面向对象技术中，经过从一个对象到另外一个对象的连续传递能够把行为传递给最有资格处理的对象，它同时消除了不少条件判断行为

领域模型的要点在于隐藏数据库的存在

3. 表模块

　　表模块是处理某一数据库表或视图中全部行的业务逻辑的一个实例

　　表模块经过强类型或弱类型的数据集与对象结合使用，使用主键查询数据，是.Net中使用的不少的一种模式，主要使用主键、半对象化的操做数据---之因此说是半结构化，是由于所用的对象基本上只具备行为，经过传入参数执行特定的操做或者查询记录集，而几乎不承载任何数据

　　在.net中，这种模式由于其容易和UI进行绑定和交互，因此倍受欢迎

4. 服务层

　　经过一个服务层来定义应用程序边界，在服务层中创建一组可用的操做的集合，并在每一个操做内部协调应用程序的响应

　　服务层是一种组织业务逻辑的模式，有点相似于业务外观；WEB SERVICE一般担任着服务层的角色

　　服务层能够经过领域外观方法和操做脚本方法实现，领域外观方法中，服务层以领域模型之上的瘦外观集合方式出现，负责实现外观的类中不不包含业务逻辑；而在操做脚本方法中 ，服务层由一组相对复杂的类组成，这些类直接实现应用逻辑，但将领域逻辑委托给封装好的领域对象类

 　　服务层的类的接口是粗粒度的，适合于远程调用。可是，在开始时，咱们应该仅设计一个本地调用的服务层，在须要远程调用时，再在服务层上增长一个远程外观。

并发管理的正确目标是尽可能增长对数据的正确访问，同时减小冲突
　　离线并发模式有两种：使用乐观离线锁、使用悲观离线锁

　　离线锁能够理解为一种非服务器管理的锁，或者说是自管理的锁，应用在适当的地方注册锁，获取数据，而后离线，并对数据进行离线的操做；其余的应用经过检测已经注册的锁来决定是否进行并发操做

1. 悲观离线锁

 　　悲观离线锁假设会话冲突的可能性很大，从而对系统的并发进性进行限制
 　　在对不一致读的要求不高时，第一选择是使用独占写锁（不能够再添加任何读锁，固然写锁也不能）；如必须读出最新数据，而不在意是否要修改，则应使用独占读锁（不能够再添加任何写锁，但读锁是容许的）。结合以上两种，提供互斥读锁的限制，又有互斥写锁的并发性的锁称为 读/写锁---读/写锁互斥不能同时加，但并发的读锁是容许的
 　　构建悲观离线锁的步骤：决定使用哪一种锁>>构建一个锁管理对象>>定义业务事务使用锁的过程
 　　让锁管理对象在锁不可用时抛出异常而不是等待锁释放，能够免除死锁
 　　悲观离线锁做为乐观离线锁的补充，只在真正须要的时候才应该使用 

2. 乐观离线锁

 　　乐观离线锁假设会话冲突的可能性很小，从而使得多用户对一份数据进行处理成为可能　　经过冲突检测和事务会滚来防止并发事务中的冲突　　本质就是经过将会话中的版本号与当前记录数据的版本号相比较，事务成功提交之后版本号增长；或者在更新的SQL语句中包含对全部字段的检查，能够不须要为数据库增长版本字段，但可能致使性能损失　　乐观离线锁必须自定检查以防止不一致读　　一个高效的合并策略能使乐观离线锁变得很是强大，当冲突发生时，合并策略能够合并更改并从新提交