1.企业应用架构模式
-
架构
-
架构的定义：最高层次的系统分解、系统中不容易改变的部分。
-
架构中最有价值的部分是：分层设计。
-
-
企业应用的特点
-
一般都涉及持久化数据
-
一般都涉及大量数据
-
一般还涉及很多人同时访问系统
-
还涉及大量操作数据的用户界面屏幕
-
通常还与企业周围的其他企业应用集成
-
还存在数据的概念不一致性
-
复杂的业务”无逻辑“
-
系统庞大，须具有”分而治之“的思想
-
-
企业应用的种类（抽象、提炼）
-
处理大量数据的系统
-
用户界面高要求的系统
-
数据管理系统
-
-
关于性能的考虑
-
响应时间
-
响应性：进度条
-
等待时间
-
吞吐率
-
负载
-
效率
-
可伸缩性
-
-
模式
-
模式最主要的是”意图“和”概要”
-
所有的模式都是行为方式的抽象概念，都是不完备的，需要不断学习完善。
-
2.分层
-
专业的人做专业的事情
-
分层的好处
-
可以将某一层当初一个有机整体来理解
-
可以替换某层的内部实现，只要提供的服务相同即可
-
可以降低耦合性，把各个层次的依赖性减到最低
-
分层有利于标准化工作
-
-
企业应用层次的演化
-
三个基本层次：表现层、领域层、数据源层
-
3.组织业务逻辑
-
业务逻辑的模式
-
三种模式：事务脚本、业务模型、表模块。
-
事务脚本：一个过程控制一个动作的逻辑。
-
业务模型：每个对象都承担一部分相关的逻辑 。
-
表模块：以表为单位设计的模式。
-
-
将处理业务逻辑分为业务层、服务层
-
服务层：放置事务控制和安全校验，提供一个易于使用的API。
-
4.映射到关系数据库
-
架构模式
-
主要时解决驱动领域逻辑访问数据库的方式
-
把领域模型和数据库完全独立，让间接层完成领域对象和数据库表之间的映射
-
-
行为问题
-
行为时从数据库读取数据以及修改数据的动作
-
需要保证数据的一致性
-
延迟加载也是必要的思想，延迟加载主要是拥有一个对象引用的占位符
-
-
读取数据
-
读取数据的方法可以看作一个查找器
-
读取数据关键的问题是性能问题
-
读取数据的准则是尽量进行批量操作，避免重复查询相同的表
-
-
结构映射模式
-
关系的映射：对象和键的映射
-
依赖映射可以简化映射关系
-
-
继承
-
单表继承：所有类建立一个表
-
具体表继承：每个具体类建立一个表
-
类表继承：一个层次的每个类建立一个表
-
-
建立映射
-
两步映射：先把内存方案转换为逻辑数据存储方案，然后从逻辑数据存储到物理数据存储
-
-
使用元数据
-
元数据映射：数据库中的列映射到对象的域。
-
-
数据库链接
-
数据库链接建立开销很大，因此需要建立一个连接池
-
一个事务必须保证每个命令都是同一个链接发出
-
链接使用完后需要关闭，一般是用垃圾回收机制关闭链接
-
避免使用select* ，使用预编译机制避免sql注入。
-
5.Web表现层
-
web服务器应用程序
-
使用脚本：接受HTTP请求数据，通过写出stream形式输出这个字符串
-
服务器页面：程序和返回的文本页组合在一起
-
把非表现层逻辑剥离出来
-
-
视图模式
-
转换视图、模板视图和两步视图
-
转换视图：程序的一种转换风格
-
模板视图：网页结构中编写表现层，页面中嵌入标签。不过这样会导致代码混乱难以维护。
-
两步视图：可以理解为前后端分离，两者独立业务逻辑更清晰，但是在性能方面有一定的损耗。
-
-
输入控制器模式
-
一个页面准备一个控制器
-
控制器分离出单独的对象，一个动作对应一个页面。
-
6.并发
-
并发问题
-
开发者能简单的避开并发问题是因为有了事务管理程序。
-
离线并发：多数据库事务中数据操作的并发控制。
-
更新丢失：A先更新数据1，然后B更新数据1，而B在A之前更新完数据。那么会导致B更新的数据就会丢失，因为B在A开始之后开始，却在A结束之前结束，导致A没有读到B的更新。
-
不一致读：A读数据过程中，B修改了数据，导致A读取的不是最新的数据。
-
-
执行语境
-
请求：应对软件工作的外部环境发出的单个调用。
-
会话：客户端和服务端长时间的交互
-
事务：多个请求看作是单个请求
-
-
隔离与不变性
-
对数据加锁
-
识别不变的数据
-
-
乐观并发控制和悲观并发控制
-
乐观锁：冲突检测，适用场景是冲突少且冲突结果不严重。
-
悲观锁：冲突避免，减少并发程度，但是会产生大量阻塞影响性能。
-
-
避免不一致读
-
悲观锁策略是读数据加一个读锁（共享锁），写数据加一个写锁（排他锁）。
-
乐观锁策略是将冲突检测建立在数据的某种版本标记上。
-
-
死锁
-
悲观锁技术有一个特别的问题就是死锁。
-
死锁：A对数据1加了锁，B对数据2加了锁，如果后面A要用到数据2，B要用到数据1。因为B对数据2加了锁，A就会等待B执行完，而B获取数据1也需要等待A执行完。这样A和B之间就出现了死锁。
-
处理死锁的一个方法是超时控制和检测机制。
-
尽量避免死锁才是最有效的解决方案：一开始获取所有锁，或者按照相同的顺序获取锁。
-
-
事务
-
ACID：原子性、一致性、隔离性、持久性。
-
长事务：跨越多个请求的事务称做长事务。
-
延迟事务：尽可能晚的打开事务，可以减少事务执行时间，但是可能会导致不一致读。
-
锁升级：如果一个事务锁住了多行数据，数据库无法处理那么多锁，就会升级为表锁。
-
减少事务隔离：可串行化的、可重复读、读已提交、读未提交。
-
可串行化：完全隔离，所有事务时串行化执行的。
-
可重复读：允许幻读，幻读就是A向一个集合中加入一批元素，而B只读到其中一部分数据。通常是插入数据引起的。
-
读已提交：重新读取已经提交的数据
-
读未提交：允许脏读，读取没有提交的数据，而这些数据又被回滚了，这种情况称之为脏读。
-
-
业务事务和系统事务
-
系统事务：通常说的数据库事务
-
业务事务：是一组业务操作，业务也期望它有ACID的属性，解决这一问题的方案是离线并发。
-
离线并发：把业务事务分成一系列的短事务。
-
业务事务最大的问题是隔离性。
-
-
-
离线并发控制的模式
-
处理离线并发问题的首选是乐观离线锁。因为它易于实现，提供最好的灵活性。
-
-
应用服务器并发