三层到现在学了有三天左右的时间了，应该写一个博客来总结梳理一下了。
是什么？
三层架构(3-tier architecture) 通常意义上的三层架构就是将整个业务应用划分为：界面层（User Interface layer）、业务逻辑层（Business Logic Layer）、数据访问层（Data access layer）。区分层次的目的即为了“高内聚低耦合”的思想。在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。
我们要学习讨论的：UI、BLL、DAL
界面层（User Interface layer）
展现给用户的界面，即用户在使用一个系统的时候他的所见所得。依据应用规模的不同，所承受的负荷会有较大的差异，另外客户端的数目，应用的复杂程度都会对其造成一定的影响。
UI的作用
- 向用户展示特定业务数据
- 采集用户的输入信息和操作
- 设计原则：用户至上，兼顾简洁
业务逻辑层（Business Logic Layer）
对数据层的操作和业务的处理。接收用户的指令或者数据输入，提交给应用层做处理，同时负责将业务逻辑层的处理结果显示给用户。相比传统的应用方式，业务层对硬件的资源要求较低。
BLL的作用
- 从DAL中获取数据，以供UI显示用
- 从UI中获取用户指令和数据，执行业务逻辑
- 从UI中获取用户指令和数据，通过DAL写入数据源
数据访问层（Date Access Layer）
直接操纵数据库，主要是增删改查的功能。存储数据的数据库服务器和处理数据和缓存数据的组件。组件将大量使用的数据放入系统的缓存库，以提高数据访问和处理的效率。
DAL的作用
- 从数据源加载数据（Select）
- 向数据源写入数据（Insert/Update）
- 从数据源删除数据（Delete）
三层为了干什么？
高内聚，低耦合
为什么要分层？
解耦
上一层依赖于下一层，如果测试下一层没有问题，那么问题就只有可能发现在本层了，便于发现和改正BUG。体现了“高内聚，低耦合”的思想。
复杂问题简单化
各个层次分工明确，将一个复杂问题简单拆分了。
便于系统维护与升级
各层间通过接口解耦，接口与实现分离，从而可以非常简单的替换掉实现，或者实际实现等。
逻辑复用（代码复用）和劳动成本的减少
例如我们现在常用的是SQL数据库，如果我们要变为Orcel数据库的话，只要数据访问层接口不变，我们可以很轻松的实现对不同数据库的实现。
团队合作开发，提高我们的工作效率
只要各层的接口在开发前规定好，那么各层开一独立开发，进行维护等等。
我们以前不分层的话，团队中每个人都需要从业务的需要分析到具体实现都要独自完成，这样的敝处：项目开发过程中对每个人的技术能力要求很高，设计的面也很广，有时也增加了开发人员的压力，最后的代码的测试、维护等等工作都会增加很多麻烦，但是多层次开发是可以解决这些问题的，分工合作、规范代码，我们可以分为需求人员、界面设计人员、代码编码人员、数据库设计人员，分工明确，都各负其职的负责好自己的任务就好，应为都流出了接口，到时之间实现不同接口的实现即可，对于人员的分配，技术强点的可以负责重要的部门的开发工作，对于简单的工作（重复性）安排新手来完成，大大的提高了我们的开发效率。
代码规范
对于每次的代码规范我们都实现制定好，制定好固定的语言开发的风格。
方面部署
将各层开发成组件，开一独立部署（现在还没有接触）。
代码的复用和劳动成本的减少
分层的根本在于代码的复用和劳动成本的减少。分层的最理想化的结果是实现层与层之间的互不依赖的内部实现，所谓的即插即用！
为了管理和维护
使软件开发有条理有秩序，一目了然，让非IT人员也能看得懂软件的框架。
原则
- DAL只提供基本的数据访问，不包含任何业务相关的逻辑处理
- UI只负责显示和采集用户操作，不包含任何的业务相关的逻辑处理
- BLL负责处理业务逻辑。通过获取UI传来的操作指令，决定执行业务逻辑，在需要访问数据源的时候直接交给DAL处理。处理完后，返回必要数据给UI