三层架构基础知识

1.什么是三层？

UI(表现层): 主要是指与用户交互的界面。用于接收用户输入的数据和显示处理后用户需要的数据。

BLL:(业务逻辑层): UI层和DAL层之间的桥梁。实现业务逻辑。业务逻辑具体包含：验证、计算、业务规则等等。

DAL:(数据访问层): 与数据库打交道。主要实现对数据的增、删、改、查。将存储在数据库中的数据提交给业务层，同时将业务层处理的数据保存到数据库。（当然这些操作都是基于UI层的。用户的需求反映给界面（UI），UI反映给BLL，BLL反映给DAL，DAL进行数据的操作，操作后再一一返回，直到将用户所需数据反馈给用户）

每一层都各负其责，那么该如何将三层联系起来呢？

1、单项引用（见下图）

2、这时候实体层（Entity）来了。（注：当然，实体层的作用不止这些）

Entity(实体层)：它不属于三层中的任何一层，但是它是必不可少的一层。

Entity在三层架构中的作用：

• 1、实现面向对象思想中的"封装";

• 2、贯穿于三层，在三层之间传递数据;（注：确切的说实体层贯穿于三层之间，来连接三层）

• 3、对于初学者来说，可以这样理解：每张数据表对应一个实体，即每个数据表中的字段对应实体中的属性（注：当然，事实上不是这样。为什么？1＞，可能我们需要的实体在数据表对应的实体中并不存在；2＞，我们完全可以将所有数据表中的所有字段都放在一个实体里）

• 4、每一层（UI—>BLL—>DAL）之间的数据传递（单向）是靠变量或实体作为参数来传递的，这样就构造了三层之间的联系，完成了功能的实现。

但是对于大量的数据来说，用变量做参数有些复杂，因为参数量太多，容易搞混。比如：我要把员工信息传递到下层，信息包括：员工号、姓名、年龄、性别、工资．．．．用变量做参数的话，那么我们的方法中的参数就会很多，极有可能在使用时，将参数匹配搞混。这时候，如果用实体做参数，就会很方便，不用考虑参数匹配的问题，用到实体中哪个属性拿来直接用就可以，很方便。这样做也提高了效率。

（注：这里为什么说可以暂时理解为每个数据表对应一个实体？？答：大家都知道，我们做系统的目的，是为用户提供服务，用户可不关心你的系统后台是怎么工作的，用户只关心软件是不是好用，界面是不是符合自己心意。用户在界面上轻松的增、删、改、查，那么数据库中也要有相应的增、删、改、查，而增删改查具体操作对象就是数据库中的数据，说白了就是表中的字段。所以，将每个数据表作为一个实体类，实体类封装的属性对应到表中的字段，这样的话，实体在贯穿于三层之间时，就可以实现增删改查数据了）

综上所述:三层及实体层之间的依赖关系:

2.三层架构是什么？

首先我们要明白三层架构的内容有哪些。官方的解释是三层架构就是为了符合“高内聚，低耦合”思想，把各个功能模块划分为表示层（UI）、业务逻辑层（BLL）和数据访问层（DAL）三层架构，各层之间采用接口相互访问，并通过对象模型的实体类（Model）作为数据传递的载体，不同的对象模型的实体类一般对应于数据库的不同表，实体类的属性与数据库表的字段名一致。

官方给的解释其实也并不难理解，我们在开发一个完整的功能模块的时候，肯定会有用户界面，根据用户的选择实现不同的代码逻辑，而逻辑处理往往大部分都是在和数据库打交道，需要对数据进行增删改查。那么为了让代码的实现更加的有条理、有逻辑，我们就把用户界面、逻辑处理、与数据库的交互分开实现，至于为什么各层之间采用接口相互访问，下面说第三点的时候着重说明。

3.为什么要用三层架构？

在真实的业务开发中，往往是需要团队合作开发的，毕竟一个完整的实际项目，它的开发周期会很长，这就意味着里面会有非常多的功能模块，比如一个简单的图书管理系统，就有管理员对图书的增删改查、对用户的增删查改，用户对图书的增删查改等等。这样的一个简单项目由一个团队来开发只需要一到两天即可，而我们却用了整整两周不止。

那么既然需要团队协同开发，自然离不开功能模块的划分了，这时候就需要使用三层架构的思想了，在三层架构中，各层互相独立，完成自己该完成的任务，项目可以多人同时开发，开发人员可以只关注整个结构中的其中某一层（自己负责的那一层即可）。举一个简单的例子，我们要在数据库查找一个人，那么首先需要一个方法去数据库查找，需要查找的条件，比如id，那么我们就初步建立了一个方法 findById(int id)，找到之后我们需要打印这个人的信息，那方法就进一个完善，有了返回值 User findById(int id)。这个方法是用来在数据库进行查询的，那万一没有这个人呢，或者找到这个人我需要把这个人进行一些列的包装处理呢？这一些列的操作我们可以把它放在逻辑处理层来，在逻辑处理层创建一个方法，处理完了之后，返回给用户界面。

从另一个方面来说，三层架构有利于各层逻辑的复用，比如上面说到的图书管理系统中管理员可以对图书进行增删查改，我们将这些方法放在一个类中，再出现对用户的增删查改时，我们就可以复用这些代码，修改参数和返回值类型即可。

这样分层处理，也更有利于代码的移植、维护，比如数据库SQLServer 转 Oracle数据库时，我们只需要修改一个层即可，因为与数据库的交互都在数据访问层中。

4.与两层的区别？

两层：

（当任何一个地方发生变化时，都需要重新开发整个系统。"多层"放在一层，分工不明确耦合度高——难以适应需求变化，可维护性低、可扩展性低）

三层：

（发生在哪一层的变化，只需更改该层，不需要更改整个系统。层次清晰，分工明确，每层之间耦合度低——提高了效率，适应需求变化，可维护性高，可扩展性高）

综上，三层架构的优势：

• 1，结构清晰、耦合度低

• 2，可维护性高，可扩展性高

• 3，利于开发任务同步进行, 容易适应需求变化

三层架构的劣势：

• 1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。

• 2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码

• 3、增加了代码量，增加了工作量

5.三层架构怎么用？

使用三层架构时，我们首先要先创建好不同的包，每一个包对应三层架构的一个层。下面我通过一个学生登录功能的案例给大家讲解三层架构的用法。

1. 首先我们在数据库中==创建了 student表==，结构如下：

   

2. 创建数据传递的载体==实体类==，一般我们将实体类放在domain/pojo/entity 这三者其中一个的包下，实体类的属性需要与数据库中的表一一对应。

   我在 src 目录下创建了存放实体类的包：entity，然后在包下创建了Student类，它的属性和数据表student的属性一一对应，然后在实体类中给各个属性创建了对应的get/set方法，创建了有参/无参构造方法以及toString()方法。

   

3. 创建==工具包util==，用于存放一些常用且不变的方法，比如IO流的读写，反反复复都是那些代码，我们就将这些重复的代码抽取出来将它封装成一个工具类，在我们需要用到这个方法的时候，直接调用即可。在验证登录这个案例里面，我们将连接数据库需要的代码抽取出来，这是因为每一次对数据库表进行增删改查访问的时候都需要连接数据库，所以将它抽取成工具类方便使用。

   

4. 创建==数据访问层dao==，在数据访问层中将对数据库表进行操作的方法写在接口 StudentDao 中，然后通过实现类 StudentImpl 写具体操作数据库表的逻辑代码。

   

   先将需要用到的方法都封装好，不写方法的实现，用到某一个方法，写这个方法的具体实现。这里我们要做的是登录验证，所以我们封装了登录方法 login ，接下来我们分析：验证登录肯定需要学生先输入用户名和密码，有了用户名和密码之后去数据库表中查对应的数据，查到了就将这个学生的信息打印出来。经过分析我们知道方法的参数就是 name 和 password ，返回值就是这个学生 Student。

   方法的具体实现，就是通过sql语句对数据库表进行操作，都是固定的模板，通过 JDBCTemplate模板 调用实现的方法即可。

   

5. 创建==业务逻辑层service==，业务逻辑层主要是对具体问题进行逻辑判断与执行操作，接收到表现层 UI 的用户指令后（用户某一步操作），会连接数据访问层 DAL进行业务处理。访问层在三层构架中位于表示层与数据层中间位置，同时也是表示层与数据层的桥梁，实现三层之间的数据连接和指令传达，可以对接收数据进行逻辑处理，实现数据的修改、获取、删除等功能，并将处理结果反馈到表示层 UI 中，实现软件功能。

   在登录案例里面，我们通过学生输入的名字和密码在数据库表里进行查找，如果没有，我们就告诉学生输入的姓名或者密码错误；如果学生输入的信息为空，那么我们就根本不用访问数据访问层的方法，直接提示用户输入错误。这一系列的逻辑判断我们都写在逻辑层service里面。

   

   

6. 创建==用户表示层view==，表示层又称表现层 UI，位于三层构架的最上层，与用户直接接触，主要是 B/S 信息系统中的 Web浏览页面，由于我们还没有使用Web页面，所以我们的用户表示层，就是现在大家写的主函数里用户输入的信息。

   

   可以看到，我们的用户界面只有一句核心代码，就是调用业务逻辑层的 loginStu() 方法，其他的处理全都通过三层架构的方式分开存放，代码的逻辑变得非常的清晰。

   ==注意：==

   这里解释为什么我们要先写接口再写实现类：使用接口是为了调用与实现解耦，带来的好处是可以各干各的。

   先从工序上说，你在写上一层的时候，会用到下一层提供的逻辑，具体表现形式就是各种各样的service类和里面的方法。上一层开搞的时候，一定会知道的一个事是下一层会干什么事，比如“将传入编号对应的人员信息设置为离职”，但下一层的代码不一定已经一行一行写出来了。所以这会儿需要有个接口，让写上层代码的人先能把代码写下去。有各种理由可以支持这种工序的合理性，比如一般来说，上一层的一行代码会对应下一层的好多行代码，那先让写上层代码的人写一遍，解决高端层面的bug，会提高很多效率。

   再从抽象角度说，不同业务模块之间的共用，不一定是共用某段代码，也可能是共用某段逻辑框架，这时候就需要抽象一个接口层出来，再通过不同的注入逻辑实现。比如模块1是登记学生信息，模块2是新闻发布，看上去风马牛不相及。但分析下来如果两个模块都有共同点，顺序都是1、验证是否有权限 2、验证输入参数是否合法 3、将输入参数转化为业务数据 4、数据库存取 5、写log，那就可以写一个service接口，里面有上述5个函数，再分别写两个service实现。具体执行的时候，通过各种注入方法，直接new也好，用spring注入也好，实现不同的效果。

   这样做的另一个目的是为了后期的维护。当软件全部编好了，测试好了，然后给用户装好了，但是过一段时间，用户用着不爽，他又让做软件的人改变一些功能，这样软件开发人员只需要改实现类里面的代码，也就是只用改一个包下代码，不用这个包改一下，那个包里的代码还要改。因为项目大了，代码就是成万上亿行，用了接口的话，就起了这个作用。

   另外，不用接口的话，假如修改了dao中的代码，因为service引用了dao中的类，那么也要改变service里面的代码，改完之后要重新编译运行，当项目比较大的时候，编译和运行很浪费时间的，而且会产生一些意外，本来只要编译dao中的代码，现在不光要编译dao中的代码，还要编译service。因为你不用接口，间接着action里的代码也要改，因为action中引用了service中的类，到最后，就变成了，牵一发而动全身本来在各个层之间用了接口只需要改一处代码的，这下可好，全要改。

   ==实在理解不了，你就记住这句真理：使用接口是为了调用与实现解耦，带来的好处是可以各干各的。==