企业应用架构模式 (简单笔记)

目标：

做什么和怎么做就够了
本书分为两部分，第一部分要细读，第二部分参考

前言

1.企业应用：
涉及大量复杂数据，各种不同的业务规则，也叫做信息系统，特点如下：
大量数据； 并发度高； 和相关系统集成； 持久化数据
最具条件性的：了解有哪些候选方法及各种方法间的优缺点比较，最后决定用那种
2.企业应用种类
对于特定的问题，要在特定的条件下选择一合适的设计，没有万能药，任何模式都有局限性
在线零售系统特点：用户量大（考虑用户突然增大时怎么办）；逻辑简单；访问方便（使用web实现，并支持各种浏览器）；数据源（可能需要与外部交互）
合同自动处理系统特点：用户量不大；业务逻辑复杂； 用户界面复杂（使用ext或富客户端实现）；交互时间长（可能2-3个小时）
小公司的开支跟踪系统：开发速度要快；可扩展；集成性要好
3.基于性能考虑
尽量避免远程调用
构建系统时，关注硬件可伸缩性比关注软件的容量或效率更有用
常见做法：先建立系统，调试运行，用基于测量的严格优化来提高性能，在做优化时要与前两次对比
4.模式
模式使用时，需要进行变化

表述——分层

1.决定建立哪些层次及每一层的功能

已经有通用的view-action-service-dao结构

2.层间消息传递

层次之间是从上向下单向依赖，尽量不要让底层依赖上层，如果需要此功能，可通过事件方式进行

3.功能该放入哪一层
在实际开发中，某一个功能该放在view还是controller不太好区分，一个办法是：假设换一种显示方式，如freemarker，是否在html和freemarker中有重复的逻辑，则这个功能应该在controller中

4.部署

客户端有利于响应时间、网络中断时；服务器端有利于系统维护

尽量不要把一层放在多个进程中完成

5.complexity booster：增加复杂度
分布、多线程、泛型差异、多平台开发及极限性能要求

表述-组织业务逻辑

三种方式transactionscript
、objectmodel（面向对象基本都是这种吧）、tablemodule（不考虑类继承和映射）。对于复杂逻辑或考虑可扩展性，基本上没悬念都是第二种
服务层：业务逻辑进一步细分为DAO层和服务层；作用：事务封装和安全检查

映射到关系数据库

1.业务对象和数据库完全独立
间接层完成业务对象和表之间的映射，完成数据库和业务对象之间所有存取操作
工作单元模式：解决数据库对象读取和修改的同步问题，大概是脏数据、不可重复读等，基本思路是：其他部分不直接调用保存方法，而是通过工作单元读取数据，保存数据。用于数据库交互比较复杂时
标识映射：当系统加载一个对象时，先检查是否已存在，是则返回它的引用，避免多次加载。
延迟加载
如果使用objectmodel，一次加载相关对象
2.读取数据
元数据映射：把映射浓缩到元数据映射上（XML映射）
连接对于事务是密不可分的，一个方法是：将其捆绑到事务中，工作单元模式很自然地适合管理事务和链接

web表现层

第九章javaweb设计

并发

1.场景：跨事务数据处理（offline concurrency），服务器端同步
；请求 client和server一次交互，会话由一系列requst组成
2.解决方法：1）分离可变与不可变数据，只有修改才会并发；2）隔离：每一片数据只能被一个执行单元访问（读写）；文件锁（只能一个修改，其他只读拷贝）可使用隔离区安排资源，设计方法是：保证每个隔离区完成尽可能的任务。
1.考虑哪些数据不变或基本不变（共享它们）；2.让只读取数据的程序使用slave数据源
乐观和悲观并发控制：（对可变数据）乐观锁考虑冲突进行提交时会提示怎么处理，当冲突很少时，应选择乐观锁，冲突较多且后果严重则选择悲观锁，悲观锁当文件编辑时，其他人不能访问。
通过时间戳进行冲突检测（乐观锁）
检测不一致读：所有读取的数据都要与共享数据进行版本标记（时间戳）比较，任何不同意味着冲突的发生，可通过分离使用过的数据（修改时间戳）和仅仅读过的数据（时间戳不变）
时序读：使用时间戳或不变标签做约束条件
死锁：强制所有人开始获取全部可能的锁，并加上时间限制

事务

请求开始时启动事务，结束时提交事务（尽量简短）
使用事务时，清楚被所中的是什么（行，表，数据库）
要在性能和错误之间折中

事务：原子性、持久性（崩溃下能保存数据）、一致性、隔离性
让业务事务支持ACID最简单的方法是在单个系统事务中，执行完整业务事务（当只需适度并发）
跨系统事务处理并发控制：乐观离线锁；在业务事务期间使用乐观的并发控制
尽量避免显示同步和锁
对类变量或全局变量考虑同步
为线程创建一个隔离区，让每次都新的对象来处理请求

会话状态

无状态会话：若在请求中不保存状态，则不用关心哪个对象来处理请求，若状态要保存，则找同一个对象来处理有状态会话，可在客户、服务器、数据库中实现。
通常将会话信息放在服务器中最容易使用，特别是会话信息不需要存储在持久介质中，也可使用客户对话状态存放数据标示号和较小的会话；数据库会话模式在集群中使用。

分布策略

远程使用的对象接口和本地使用的有所区别：本地接口细粒度（扩展性）； 远程接口要粗粒度（一次得到大量信息，最小化远程调用的数量）
利用多处理器资源：使用集群系统，在每个处理器上都部署所有的对象，并在其他几个几点复制它们
系统中每个地方尽量减少远程调用，调用接口选择更高效，而非XML
若两个系统使用相同平台构建，最好使用该系统的远程调用机制，webservice更适合跨平台的。
异步的，基于消息的处理方式。

通盘考虑：设计企业应用

1.从领域层开始

优先考虑业务对象模型：简单问题也可，复杂问题非你莫属

2.深入到数据源层

领域模型的数据源：行数据（对应表中一行，逻辑简单时）；数据库映射（类和表不是一一映射）；使用工作单元（ThreadLocal）进行并发控制（映射工具有）

3.表现层

胖客户界面：extJs、MVC等

4.具体的建议

存储过程与数据库处于同一过程中，速度最快，但会和数据库绑定，除非有很强的性能开销，否则不适用