使用POJO名称是为了避免和**EJB(Enterprise JavaBean)混淆起来, 而且简称比较直接. 其中有一些属性及其getter setter方法的类**,没有业务逻辑，有时可以作为VO(value -object)或dto(Data Transform Object)来使用.当然,如果你有一个简单的运算属性也是可以的,但不允许有业务方法,也不能携带有connection之类的方法

POJO与javabean的区别#

DispatcherServlet作用#

DispatcherServlet是前端控制器设计模式的实现,提供Spring Web MVC的集中访问点,而且负责职责的分派,而且与Spring IoC容器无缝集成,从而可以获得Spring的所有好处。

在web.xnl文件中配置DispatchServlet

DispatcherServlet主要用作职责调度工作,本身主要用于控制流程,主要职责如下：

**　　1、文件上传解析,如果请求类型是multipart将通过MultipartResolver进行文件上传解析;
　　2、通过HandlerMapping,将请求映射到处理器(返回一个 HandlerExecutionChain ,它包括一个处理器、多个HandlerInterceptor拦截器);
　　3、通过HandlerAdapter支持多种类型的处理器( HandlerExecutionChain中的处理器);**

**　　4、通过ViewResolver解析逻辑视图名到具体视图实现;
　　5、本地化解析;
　　6、渲染具体的视图等;
　　7、如果执行过程中遇到异常将交给HandlerExceptionResolver来解析。**

上下文关系，也是在web.xml中配置#

集成Web环境的通用配置:

1
2
3
4
5
6
7
8
9
10
11
12
13

<!-- Spring集成WEB环境的通用配置，一般用于加载除Web层的Bean(如DAO、Service等),以便于与其他任何Web框架集成 -->
<!-- Spring 的监听器可以通过这个上下文参数来获取beans.xml的位置 -->
<context-param>
	<param-name>contextConfigLocation</param-name>
	<param-value>
		classpath:beans.xml
	</param-value>
</context-param>
<!-- 创建Spring的监听器 -->
<listener>
	<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

如上配置是Spring集成Web环境的通用配置;一般用于加载除Web层的Bean(如DAO、Service等),以便于与其他任何Web框架集成。

重要的接口和类的简单说明：

DispatcherServlet：前端控制器，用于接收请求。

HandlerMapping接口：用于处理请求的映射。

　　DefaultAnnotationHandlerMapping：HandlerMapping接口的实现，用于把一个URL映射到具体的Controller类上。

HandlerAdapter接口：用于处理请求的映射。

　　AnnotationMethodHandlerAdapter：HandlerAdapter接口的试下，用于把一个URL映射到对应Controller类的某个方法上。

ViewResolver接口：用于解析View。

　　InternalResourceViewResolver：ViewResolver接口的实现，用于把ModelAndView的逻辑视图名解析为具体的View。

参考阿里巴巴Java开发手册

应用分层：

分层领域模型规约：

DO/PO/entity（ Data Object）：与数据库表结构一一对应，通过DAO层向上传输数据源对象。

DTO（ Data Transfer Object）：数据传输对象，Service或Manager向外传输的对象。

BO（ Business Object）：业务对象。 由Service层输出的封装业务逻辑的对象。

AO（ Application Object）：应用对象。 在Web层与Service层之间抽象的复用对象模型，极为贴近展示层，复用度不高。

VO（ View Object）：显示层对象，通常是Web向模板渲染引擎层传输的对象。

POJO（ Plain Ordinary Java Object）：在本手册中， POJO专指只有setter/getter/toString的简单类，包括DO/DTO/BO/VO等。

Query：数据查询对象，各层接收上层的查询请求。 注意超过2个参数的查询封装，禁止使用Map类来传输。

参考

1
2

https://zhuanlan.zhihu.com/p/102389552

VO（Value Object）值对象

VO就是展示用的数据，不管展示方式是网页，还是客户端，还是APP，只要是这个东西是让人看到的，这就叫VO

VO主要的存在形式就是js里面的对象（也可以简单理解成json） 

VO是可以第一个优化掉的，展示业务不复杂的可以压根儿不要，直接用DTO

PO（Persistant Object）持久对象

简单说PO就是数据库中的记录，一个PO的数据结构对应着库中表的结构，表中的一条记录就是一个PO对象

通常PO里面除了get，set之外没有别的方法

对于PO来说，数量是相对固定的，一定不会超过数据库表的数量

等同于Entity，这俩概念是一致的

BO（Business Object）业务对象

BO就是PO的组合

简单的例子比如说PO是一条交易记录，BO是一个人全部的交易记录集合对象

复杂点儿的例子PO1是交易记录，PO2是登录记录，PO3是商品浏览记录，PO4是添加购物车记录，PO5是搜索记录，BO是个人网站行为对象

BO是一个业务对象，一类业务就会对应一个BO，数量上没有限制，而且BO会有很多业务操作，也就是说除了get，set方法以外，BO会有很多针对自身数据进行计算的方法

为什么BO也画成横跨两层呢？原因是现在很多持久层框架自身就提供了数据组合的功能，因此BO有可能是在业务层由业务来拼装PO而成，也有可能是在数据库访问层由框架直接生成

很多情况下为了追求查询的效率，框架跳过PO直接生成BO的情况非常普遍，PO只是用来增删改使用

BO和DTO的区别

这两个的区别主要是：BO进行字段的删减，得到DTO

BO对内，为了进行业务计算需要辅助数据，或者是一个业务有多个对外的接口，BO可能会含有很多接口对外所不需要的数据，因此DTO需要在BO的基础上，删减一些字段，只要自己需要的数据，然后对外提供

在这个关系上，通常不会有数据内容的变化，内容变化要么在BO内部业务计算的时候完成，要么在解释VO的时候完成

一些工具类的系统和一些业务不是很复杂的系统DTO是可以和BO合并成一个，当业务扩展的时候注意拆分就行

VO和DTO的区别

主要有两个区别

一个是字段不一样，VO根据需要会删减一些字段

另一个是值不一样，VO会根据需要对DTO中的值进行展示业务的解释

举个简单的例子

DTO可能是这样的

1
2
3
4
5

{
    "gender":"男", 
    "age":35 
} 

对于业务一来说只需要性别，而且因为是一个古风聊天室，也不能直接展示男，因此经过业务解释业务一的VO是

1
2
3
4

{ 
    "gender":"公子" 
} 

对于业务二来说只需要年龄，而且不需要精确的年龄，因此经过业务解释业务二的VO是

1
2
3
4

{ 
    "age":"30~39" 
} 

DAO设计模式