- 一般的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来获取你想要的对象了。