Spring MVC学习笔记——POJO和DispatcherServlet
使用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环境的通用配置:
<!-- 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类来传输。
参考
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可能是这样的
{
"gender":"男",
"age":35
}
对于业务一来说只需要性别，而且因为是一个古风聊天室，也不能直接展示男，因此经过业务解释业务一的VO是
{
"gender":"公子"
}
对于业务二来说只需要年龄，而且不需要精确的年龄，因此经过业务解释业务二的VO是
{
"age":"30~39"
}
DAO设计模式
