java三层架构实例-为什么要用三层架构？实例测试1、4个方面

三层架构是我们没有接触过的新知识，那么我们在学习它的时候，就应该和之前学习其他内容一样，从以下四个方面去了解学习它：

三层架构是什么？

为什么要用三层架构？

三层架构怎么用？

实例测试

1、三层架构是什么？

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

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

2、为什么要用三层架构？

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

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

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

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

3、三层架构怎么用？

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

首先我们在数据库中创建了user表，结构如下：

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

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

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

创建数据访问层DAL，在数据访问层中将对数据库表进行操作的方法写在接口 UserDao

中，然后通过实现类UserDaoImpl写具体操作数据库表的逻辑代码。

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

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

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

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

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

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

注意：

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

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

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

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

另外，不用接口的话，假如修改了dao中的代码，因为service引用了dao中的类，那么也要改变service里面的代码，改完之后要重新编译运行，当项目比较大的时候，编译和运行很浪费时间的，而且会产生一些意外，本来只要编译dao中的代码，现在不光要编译dao中的代码，还要编译service。因为你不用接口，间接着action里的代码也要改，因为action中引用了service中的类，到最后，就变成了，牵一发而动全身本来在各个层之间用了接口只需要改一处代码的，这下可好，全要改，举个不太恰当的例子：好比，我摔了一跤，小腿摔断了，小腿断了，因为没用接口，间接着，大腿也断了，接着，屁股开花了，接着，上身也感染了。最后gg了。可能不太恰当，但是有助于你理解。

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

4、 实例测试

通过对上述三层架构的学习，下面大家在上面这个案例的基础之上完成 学生的注册功能，分析：

注册相当于往数据库表中添加一条数据。

注意用代码判断输入的信息是否有误。