spring---web项目结构分层

1. 一般的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

　

　　filter是javax.servlet 包中的过滤器，它的加载与控制不受Spring容器的影响，一般由web容器如tomcat通过web.xml来进行加载，所以在使用filter时，我们无法通过spring注解的方式来获取spring创建的对象。

　　

 

　　但如果碰到如filter来判断用户是否登陆，我们必须使用spring所创建的缓存对象，怎么办。这是我们只需要spring中的DelegatingFilterProxy类来对你的filter进行代理，而

DelegatingFilterProxy可以在spring中进行注册，然后DelegatingFilterProxy再将你的filter注册进入spring中，这是你就可以使用@Resource,或者@Autowire来获取你想要的对象了。

转载于:https://www.cnblogs.com/sospopo/p/9373705.html