JavaWEB【三层架构】

如需温习上一节的内容，请点击下方链接进行跳转：

javaweb之文件上传与富文本编辑器_云彩123的博客-CSDN博客目录一、web文件上传与下载1、概述：2、原理：3、实现方式：4、SmartUpload组件使用：二、富文本编辑器1、概述：2、常用的富文本编辑器：3、CKeditor的使用步骤：如需温习上一节的内容，请点击下方链接：javaweb之application&javabean封装_云彩123的博客-CSDN博客目录一、application1、概述：2、常用方法：3、经典案例：application实现统计网站访客4、application对象常用的方法https://blog.csdn.net/m0_64522859/article/details/124089762

---

目录

一、什么是三层：

Etytity在三层架构中的作用：

他们三者是如何联系的？

二、为什么使用三层？

三、与两层的区别？？

1.Javaweb经历了三个时期

2.JavaWeb经典三层框架

软件分层模式

---

一、什么是三层：

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

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

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

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

1、单项引用（见下图）

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

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

Etytity在三层架构中的作用：

• 1、实现面向对象思想中的"封装";
• 2、贯穿于三层，在三层之间传递数据;（注：确切的说实体层贯穿于三层之间，来连接三层）
• 3、对于初学者来说，可以这样理解：每张数据表对应一个实体，即每个数据表中的字段对应实体中的属性（注：当然，事实上不是这样。为什么？1＞，可能我们需要的实体在数据表对应的实体中并不存在；2＞，我们完全可以将所有数据表中的所有字段都放在一个实体里）
• 4、每一层（UI—>BLL—>DAL）之间的数据传递（单向）是靠变量或实体作为参数来传递的，这样就构造了三层之间的联系，完成了功能的实现。

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

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

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

思想来源于生活：

服务员：只管接待客人；

厨师：只管做客人点的菜；

采购员：只管按客人点菜的要求采购食材；

他们各负其职，服务员不用了解厨师如何做菜，不用了解采购员如何采购食材；厨师不用知道服务员接待了哪位客人，不用知道采购员如何采购食材；同样，采购员不用知道服务员接待了哪位客人，不用知道厨师如何做菜。

他们三者是如何联系的？

比如：厨师会做：炒茄子、炒鸡蛋、炒面——此时构建三个方法（ cookEggplant()、cookEgg()、cookNoodle())

顾客直接和服务员打交道，顾客和服务员（UI层）说：我要一个炒茄子，而服务员不负责炒茄子，她就把请求往上递交，传递给厨师（BLL层），厨师需要茄子，就把请求往上递交，传递给采购员（DAL层），采购员从仓库里取来茄子传回给厨师，厨师响应cookEggplant()方法，做好炒茄子后，又传回给服务员，服务员把茄子呈现给顾客。

这样就完成了一个完整的操作。

在此过程中，茄子作为参数在三层中传递，如果顾客点炒鸡蛋，则鸡蛋作为参数（这是变量做参数）。如果，用户增加需求，我们还得在方法中添加参数，一个方法添加一个，一个方法设计到三层；何况实际中并不止设计到一个方法的更改。所以，为了解决这个问题，我们可以把茄子、鸡蛋、面条作为属性定义到顾客实体中，一旦顾客增加了炒鸡蛋需求，直接把鸡蛋属性拿出来用即可，不用再去考虑去每层的方法中添加参数了，更不用考虑参数的匹配问题。

这样讲，不知道大家是不是可以明白。（待会实例解释吧）

---

二、为什么使用三层？

使用三层架构的目的：解耦！！！

同样拿上面饭店的例子来讲：

（1）服务员（UI层）请假——另找服务员；厨师（BLL层）辞职——招聘另一个厨师；采购员（DAL）辞职——招聘另一个采购员； （2）顾客反映：

• 1、你们店服务态度不好——服务员的问题。开除服务员；
• 2、你们店菜里有虫子——厨师的问题。换厨师；

任何一层发生变化都不会影响到另外一层！！！

---

三、与两层的区别？？

两层：

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

三层：

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

综上，三层架构的优势：

• 1，结构清晰、耦合度低
• 2，可维护性高，可扩展性高
• 3，利于开发任务同步进行, 容易适应需求变化

三层架构的优劣势：

• 1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
• 2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码
• 3、增加了代码量，增加了工作量

---

1.Javaweb经历了三个时期

①JSP Model1第一代

JSP Model1是JavaWeb早期的模型，它适合小型Web项目，开发成本低！Model1第一代时期，服务器端只有JSP页面，所有的操作都在JSP页面中，连访问数据库的API也在JSP页面中完成。也就是说，所有的东西都耦合在一起，对后期的维护和扩展极为不利。

②JSP Model1第二代

JSP Model1第二代有所改进，把业务逻辑的内容放到了JavaBean中，而JSP页面负责显示以及请求调度的工作。虽然第二代比第一代好了些，但还让JSP做了过多的工作，JSP中把视图工作和请求调度（控制器）的工作耦合在一起了。

③JSP Model2

JSP Model2模式已经可以清晰的看到MVC完整的结构了。

·JSP：视图层，用来与用户打交道。负责接收用来的数据，以及显示数据给用户；

·Servlet：控制层，负责找到合适的模型对象来处理业务逻辑，转发到合适的视图；

JavaBean：模型层，完成具体的业务工作，例如：开启、转账等。

这就是javaweb经历的三个年代，JSP Model2适合多人合作开发大型的Web项目，各司其职，互不干涉，有利于开发中的分工，有利于组件的重用。但是，Web项目的开发难度加大，同时对开发人员的技术要求也提高了。

2.JavaWeb经典三层框架

我们常说的三层框架是由JavaWeb提出的，也就是说这是JavaWeb独有的！

所谓三层是表述层（WEB层）、业务逻辑层（Business Logic），以及数据访问层（Data Access）。

·WEB层：包含JSP和Servlet等与WEB相关的内容；

·业务层：业务层中不包含JavaWeb API，它只关心业务逻辑；

·数据层：封装了对数据库的访问细节；

　　注意，在业务层中不能出现JavaWeb API，例如request、response等。也就是说，业务层代码是可重用的，甚至可以应用到非Web环境中。业务层的每个方法可以理解成一个万能，例如转账业务方法。业务层依赖数据层，而Web层依赖业务层！

---

软件分层模式

1.为什么需要分层

 业务处理的代码与JSP代码混在一起，不易于阅读，不易于代码维护，采用三层软件设计架构后，软件系统在可扩展性和可复用性方面得到极大提高，

2.软件设计中的分层模式
分层模式是最常见的一种架构模式；甚至可以说分层模式是很多架构模式的基础。

3.分层
    ①分层模式是将解决方案的组件分隔不同的层中（分工合作，细化）
    ②每一层的组件应保持内聚性（部门之间常联系）
    ③每一层都应与其下面的各层保持松耦合

4.三层架构：表示层、业务逻辑层、数据访问层
    ①表示层：位于最外层 ( 最上层 )，使用户能够直接访问，用于显示数据和接收用户输入的数据，为用户提供一种交互式操作界面。在 Web 应用程      序中，表示层一般以 JSP 文件、HTML文件为主；

    ②业务逻辑层：其主要功能是提供对业务逻辑处理的封装，在业务逻辑层中，通常会定义些接口，表示层通过调用业务逻辑层的接口实现各种操作，      如数据有效性的检验. 业务辑描述等相关功能，业务逻辑层经常放在 service 包或 biz 包下，btz 是英文 buslness 的缩写，意思是 '业务逻      辑"；

    ③数据访问层：该层实现对数据的保存和读取操作。数据访问，可以访问关系数椐库、文件或 XML 文档等。数据访问层通常放在 dao 包下，DAO 是      英文 Data Access Object 的缩写，意思是 "数据访问对象 "；

5、解释“强内聚，松耦合”：

IT界有一句很著名的口号：强内聚、松耦合。

　　即使是最初级的程序员，在常常的被教导中，他也了解了这句口号的含义：我们的程序要模块化，模块要完成明确的一组关联的服务功能，要求它的各部分是相关的、有机组合起来是完整体（外部程序来看黑盒子），模块的内部各成分之间相关联程度要尽可能高（强内聚）；而模块与模块之间又要求是可分拆的、少依赖的（松耦合）。

　　人们易于实现强内聚的模块，例如：一个函数实现一个独立的功能，这就是强内聚。

　　人们不易实现松耦合，因为，孤独的模块毫无意义，只有模块间的相互协调地工作，才能实现系统的目的。而对于模块间的相互关系的设计，没有一定的经验是难以把握。耦合的强度依赖于：（1）一个模块对另一个模块的调用；（2）一个模块向另一个模块传递的数据量；（3）一个模块施加到另一个模块的控制的多少；（4）模块之间接口的复杂程度。等等。

　　当然，“强内聚、松耦合”也是有矛盾的，如：内聚性越强，则要求的函数越多（每个函数只作一件“事”），这样，将它们组合成“大”的功能，也就越复杂，就不可能达到松耦合。因此，应在二者之间作出平衡与折衷的选择，这也体现程序员的水平。从系统论的角度来看，系统是有层次的，即系统可以分为子系统，模块可分为子模块，“强内聚、松耦合”的“度”的把握，应结合系统的次层性来考虑，即通常应在层次性上作出折衷，如：模块内子程序（下一个层次上）应共享数据（有一定的耦合度），而减少全局变量能降低子程序性间的耦合性。

　　面向对象的语言进一步强化了“强内聚、松耦合”，类的封装性既强调了相关内容（数据及其操作）的内聚，又强调了类的独立性和私密性。而类的继承性以及友元等，就是在松耦合的原则下规范了类之间的关联关系。类与类之间通常通过接口的契约实现服务提供者/服务请求者模式，这就是典型的松耦合。

　　“强内聚、松耦合”对于程序编写分工、程序的可维护性以及测试都有重要的关系，如：从设计角度来看，在“强内聚、松耦合”的指导下进行的设计得到的程序模块，符合项目管理的WBS（工作分解结构）的要求，其相对独立的模块可以分配到具体的程序员进行开发，另外，程序编码外包也必须建立在这种原则的设计之下；从程序生命期角度来看，它有利于提高程序质量，特别是方便于程序的日后维护，即程序模块的相对独立性是可维护性的保证；再从测试角度来看，符合“强内聚、松耦合”的程序，易于对局部（模块）进行黑盒测试，也易于编写测试用的“桩”和“驱动”。

　　“强内聚、松耦合”也是对组织结构的要求，项目组分为几个小组（正式的或非正式的），各小组的工作应是高度相关的，各小组之间的工作应尽量是较少相关或有明确的接口，从而减少沟通成本。其实，“强内聚、松耦合”是系统中应遵守的普遍原则，我们在许多领域都可以找到它的应用。

　　“强内聚、松耦合”是我们不得不念的“三字经”，我们一定要念好它