【三层架构】——初相识

前言

三层架构(3-tier architecture) 从开始到现在中间夹杂着考试已经拖拖拉拉好久了，现在打算把三层踏踏实实做一下总结，开始的时候思维非常乱，慢慢的总结也就是在整理自己的思绪吧。

下面这个图是对三层的一个宏观把握：

what

例子：如在饭店里有服务员、厨师、采购员他们三者各司其职互不影响，这里服务员起到和客户进行交互的作用也就是表示层；厨师是把服务员的指令进行加工，同时告诉采购员需要的食品，相当于业务逻辑层；采购员是直接和食品打交道的，相当于数据访问层。如果其中有一方不能工作，可以随时找人替换而不影响工作进行。




按照逻辑上划分：

显示层UI：向用户展现特定业务数据；采集用户的输入信息和操作

业务逻辑层BLL：从DAL中获取数据在UI层中显示；从UI中获取用户指令和数据，执行业务逻辑，通过DAL写入数据源DB。起到承上启下的作用。

数据访问层DAL：从数据源中select、insert、update、delete数据。可以访问数据库系统、二进制文件、文本文档或是XML文档。

原理：

3个层次中，系统主要功能和业务逻辑都在业务逻辑层进行处理。 　　

所谓三层体系结构，是在客户端与数据库之间加入了一个“中间层”，也叫组件层。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与数据库进行交互。

三层数据传递关系：




数据访问层的类，直接访问数据库，实现基本记录操作。

业务逻辑层的类，调用相关的数据访问类，实现用户所需功能。

界面层：部署控件后，调用业务逻辑层的类，实现功能。

我的理解：

三层架构也就是把我们原来权力职责集于一身的制度（所有代码都写在一起）改变成不同层次各司其职（分层），每个层之间按照既定的制度和规则进行游戏，其中如若出现意外或是中断，可以立即更换部分零件而不影响全局。

why

对比两层和三层：




思想：高内聚、低耦合。

优点：

1.分工明确：开发人员可以只关注整个结构中的其中某一层。

2.角色替换：可以很容易的用新的实现来替换原有层次的实现。

3.低耦合性：可以降低层与层之间的依赖。

4.高内聚性：利于各层逻辑的复用。

5.有利于标准化。

缺点：

1.降低了系统的性能。因为多了中间层自然多了一些程序，降低系统性能。

2.有时会导致级联的修改。如果某一层功能修改会导致其它层响应的修改。

when

当有数据访问和业务逻辑时，当然大部分情况下都有，在系统是大中型应用程序时我们可以选择用三层，它可以使设计阶段有很清晰的思路，便于分工明确，便于后期的维护。如果系统过小，使用三层，反而会使设计繁琐复杂。

how

1.找到三层之间的依赖传递关系

2.增加关系请求响应

3.建立数据库

4.连接数据库

注：实体类贯穿整体，是公共可以调用的模块，在下篇博客中会详细说明。

尾音

三层其实就是把我们平常生活中分工合作转移到代码中来，艺术源于生活高于生活，用心去发现。