spring---web项目结构分层

最新推荐文章于 2025-06-17 15:41:55 发布

转载最新推荐文章于 2025-06-17 15:41:55 发布 · 614 阅读

1 ·

CC 4.0 BY-SA版权

原文链接：http://www.cnblogs.com/sospopo/p/9373705.html

文章标签：

#java #数据库 #前端 #ViewUI

本文探讨了前后端分离架构下WEB API与JSON交互的工作原理，介绍了常见的领域模型及其应用场景，包括DO、DTO、BO、AO及VO等，并讨论了filter在Spring框架中的集成方法。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一般的web结构

　　在前后台分离的情况下，我们对前端一般会以WEB API的形式同过JSON交互来与前端进行交互。一般来讲，我们的数据模型会在controller层进行交互，进行数据的校验与处理，然后交给service层进行相应的逻辑处理。如果service需要与数据库的支持，则调用dao层来获取与存储数据。这样分层的好处是当我们的数据存储方式发生了变化，如我们的数据库从oracle变成了mysql，我们只要改一下dao层的配置，不会影响我们的业务代码，特别注意的是，如果service层在调用不同的表时，我们最好调用对应表的service层的方法，不应该出现一个service调用多个dao的情况。

　　2.分层领域模型

在阿里巴巴编码规约中列举了下面几个领域模型规约:

DO（Data Object）：与数据库表结构一一对应，通过DAO层向上传输数据源对象。
DTO（Data Transfer Object）：数据传输对象，Service或Manager向外传输的对象。
BO（Business Object）：业务对象。由Service层输出的封装业务逻辑的对象。
AO（Application Object）：应用对象。在Web层与Service层之间抽象的复用对象模型，极为贴近展示层，复用度不高。
VO（View Object）：显示层对象，通常是Web向模板渲染引擎层传输的对象。
Query：数据查询对象，各层接收上层的查询请求。注意超过2个参数的查询封装，禁止使用Map类来传输。

而对于数据模型也就是我们所谓的bean来讲，我们最好在不同的层里面使用不同的对象。因为这样可以更灵活的操控不同层的数据

但每一个层基本都自己对应的领域模型，这样就导致了有些人过于追求每一层都是用自己的领域模型，这样就导致了一个对象可能会出现3次甚至4次转换在一次请求中，当返回的时候同样也会出现3-4次转换，这样有可能一次完整的请求-返回会出现很多次对象转换。如果在开发中真的按照这么来，恐怕就别写其他的了，一天就光写这个重复无用的逻辑算了吧。

　　　　3.filter与spring