分层架构

分层架构，也叫N层架构

是大多数JavaEE应用的实际标准传统IT公司的组织架构和分层模式十分相似，大多数应用的架构模式优点    易于开发，测试缺点    伸缩性，灵活性

1.模式分析

组件被分成几个平行的层次，每一层代表了应用的一个功能（展示逻辑或业务逻辑）大多数的架构都分四种层： 展示层，业务层，持久层，数据库层每层都有着特定职能    展示层处理界面以及交互    业务层处理请求对应的业务架构里的层次是具体工作的高度抽象，为了实现某种特定的业务请求    展示层并不关心怎样得到用户数据，它只在屏幕上展示信息，    业务层不关心展示，也不关心用户数据从哪里来，它只需要从持久层得到数据，执行数据有关的业务，然后传递给展示层关注点分离    一层组件只处理本层逻辑，展示层只处理展示，业务层处理业务    让我们更容易构造角色和模型，更好开发，测试，维护

2.关键概念

每层都是封闭的，request必须一层层传递，    展示层-->业务层-->持久层-->数据层为什么不允许展示层直接访问数据层？    如果只是读取数据，展示层直接访问数据层，比穿过一层层得到数据块多了    层隔离        某一层的改变不影响其他层，这些变化仅影响当前层，        展示层访问持久层，假如持久层SQL变了，对业务层，展示出就有了影响，这会让组件之间相互依赖，架构会难以维护封闭架构的不变    想往组件添加一个分享服务层，因为架构限制了分享服务层访问业务层，    如果没有隔离层，就没有限制展示层访问，难以进行权限管理

3.注意事项

污水池反模式    请求流只是简单的穿过层次，不留一点云彩    请求 --> 展示层 --> 业务层 --> 持久层 --> 数据库     数据按照原路返回，不会有任何的二次处理80-20 确定架构是否处于反污水模式    20%请求仅仅是简单穿越    80%请求做一些业务逻辑操作    如果这个比例相反，那么开发架构层会比较好，不过由于缺少层次隔离，项目会难以控制

4.模式分析 分层架构

整体灵活性 低    响应环境变化的能力，想在这种架构做一些改变，是费时费力的    分层的笨重以及组件间的紧耦合导致灵活性降低易于部署 低    一个组件的小改动会影响到整个程序的发布，    发布必须按照计划，应用发布不流畅，降低了灵活性可测试性 高    组件处于各自的层次，可模拟其它层，很容易测试性能  低    一次业务请求穿越所有架构层，做了很多不必要的工作伸缩性 低    总体关系过于紧密，很难扩展易开发性 容易    这种架构大家都熟悉，不难实现