在Javaweb中如何体现三层架构思想

一个非常好的问题。三层或者多层架构的核心思想是分层，不同粒度和维度都有应用。

一，系统架构常见的动静分离、数据中台、微服务在一定程度上都是将系统实现进行分层解耦，从而使得系统表现为不同的层次，比如典型的前端页面展示、接口服务、数据存储。

文章插图
二，前端架构以典型的Ant Design开发信息管理系统为例，将前端实现分为Page、Model、Service三层， Page展示页面响应用户操作， Model保存数据， Service处理业务逻辑、调用后台服务接口。
【在Javaweb中如何体现三层架构思想】

文章插图

三，后端架构在后端开发中，仍然会采用分层架构。比如常用的Java + Spring Boot框架开发Web服务时，有Controller ， Service ， Entity ，分别封装

文章插图

我是工作多年的Web应用架构师，欢迎关注我，了解更多IT专业知识。
我觉得这个三层架构是个不同阶段理解不同的概念。
我们最开始做项目的时候，对于java而言就是servlet、jsp之流（像.net等应该就是asp或者asp.net) ，甚至直接将业务逻辑写在jsp页面里面，没有什么层的概念，一个jsp就打天下了。开发时爽的不行，连上数据库， curd搞起来，数据页面一绑定，我们就万事大吉了，干他什么业务变更，业务扩展呢，那是leader的事，和我有什么关系。
然后悲剧就开始发生了，我们的产品很快找到了老大，我们最近业务要扩展了，我们一想这还不简单，直接在页面上加链接，加新的jsp页面就行了，说干就干，继续在jsp里面翻云覆海，很快搞定了，这样的事情在一年内发生了百次以上，之后产品找到老大，说我们的计算方式变化了，页面不变，但是数据都不对了，我们需要重写下业务计算的方式，一部分还是原来的逻辑，一部分变更成新的，这下我们就犯难了，这上百个jsp ，每个里面都是大量的逻辑，数据库查询，修改等操作，这怎么把业务按数据拆分开啊，最终直接删代码跑路喽。。。
刚才废了好多话就是想描述下在三层架构没有流行起来前开发的模式和弊端，工笔不好，大家见谅吧，总体想表达的也就是三层架构为什么要出现，解决的是什么问题。

我先上定义：
三层架构(3-tier architecture) 通常意义上的三层架构就是将整个业务应用划分为：界面层（User Interface layer）、业务逻辑层（Business Logic Layer）、数据访问层（Data access layer）。区分层次的目的即为了“高内聚低耦合”的思想。在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推荐的分层式结构一般分为三层，从下至上分别为：数据访问层（又称为持久层）、业务逻辑层（又或称为领域层）、表示层。
表示层（UI层）: 表示层也称为界面层，位于最外层（最上层），离用户最近。用于显示数据和接收用户输入的数据，为用户提供一种交互式操作的界面。
业务逻辑层（BLL层）: 负责关键业务的处理和数据的传递。复杂的逻辑判断和涉及到数据库的数据验证都需要在此做出处理。主要是针对具体的问题的操作，也可以理解成对数据层的操作，对数据业务逻辑处理，如果说数据层是积木，那逻辑层就是对这些积木的搭建。
数据访问层（DAL层）：主要负责对数据库的直接访问，为业务逻辑层提供数据，根据传入的值来操作数据库，增、删、改、查。

文章插图

说白了就是一句话，把上面我说的那100多个jsp页面里面的业务逻辑抽取出来，按角色分成上面的三层。
这样就可以让我们的代码达到“高内聚，低耦合”的目的，每层需要修改不会影响其他层，便于发现和改正BUG 。还有比较关键的一点是代码的复用和劳动成本的减少，分层的最理想化的结果是实现层与层之间的互不依赖的内部实现，所谓的即插即用！
我觉得最重要的一点是便于团队开发过程中的管理，三层架构使得合作开发成为可能，由于各层相互独立，一个小组只需负责一小块就可以。结构化的编程方法面对大型的项目会感到力不从心，因为结构化设计必定会使程序变的错综复杂。逻辑主要在BLL层，就使得UI层也就是客户端不承担太多的职责，即使更新业务逻辑，也无需修改客户端，不用重新部署。

擦，写了这么多才发现我回答错了主题，题主想问的是如何更好的体现，哎算了，不改了，发出去就算帮题主加个热度吧....