SpringMVC架构
MVC设计模式
MVC设计模式的任务是将包含业务数据的模块与显示模块的视图解耦。通过在模型和视图间添加控制转发模块实现。控制器接收请求,发送给模型进行处理,然后通知视图模型更改的消息。
Springmvc框架结构
HandlerMapping保存了url和Handler的映射关系,可以根据用户请求的URL找到指定的Handler;Handler处理器可以简单的看为我们编写的业务处理方法。
架构流程
- 用户发送请求至前端控制器DispatcherServlet。
- DispatcherServlet收到请求调用HandlerMapping处理器映射器。
- 处理器映射器根据请求url找到具体的处理器,生成处理器对象及处理器拦截器(如果有则生成)一并返回给DispatcherServlet。
- DispatcherServlet通过HandlerAdapter处理器适配器调用处理器。
- 执行处理器Handler。
- Handler执行完成返回ModelAndView。
- HandlerAdapter将Handler执行结果ModelAndView返回给DispatcherServlet。
- DispatcherServlet将ModelAndView传给ViewReslover视图解析器。
- ViewReslover解析后(加上具体的前缀、后缀并生成view视图对象,这个视图解析器可以不配)返回具体View。
- DispatcherServlet对View进行渲染视图(即将模型数据填充至视图中)。
- DispatcherServlet响应用户。
需要分清三个概念:处理器映射器(HandlerMapping)、处理器(Controller)、处理器适配器(HandlerAdapter)
组件说明
DispatcherServlet
前端控制器,用户请求到达前端控制器,相当于mvc模式中的c,dispatcherServlet是整个流程控制的中心,由它调用其它组件处理用户的请求,dispatcherServlet的存在降低了组件之间的耦合性。
HandlerMapping
处理器映射器,HandlerMapping负责根据用户请求找到Handler处理器,springmvc提供了不同的映射器实现不同的映射方式,例如:配置文件方式,实现接口方式,注解方式等。
Handler:处理器
Handler 是继DispatcherServlet前端控制器的后端控制器,在DispatcherServlet的控制下Handler对具体的用户请求进行处理。
HandlAdapter
处理器适配器,通过HandlerAdapter对处理器进行执行,这是适配器模式的应用,通过扩展适配器可以对更多类型的处理器进行执行。
View Resolver
视图解析器,View Resolver负责将处理结果生成View视图,View Resolver首先根据逻辑视图名解析成物理视图名即具体的页面地址,再生成View视图对象,最后对View进行渲染将处理结果通过页面展示给用户。
View
视图,springmvc框架提供了很多的View视图类型的支持,包括:jstlView、freemarkerView、pdfView,jsp等。一般情况下需要通过页面标签或页面模版技术将模型数据通过页面展示给用户。
RequestMappingHandlerMapping
注解式处理器映射器,对类中标记@ResquestMapping的方法进行映射,根据ResquestMapping定义的url匹配ResquestMapping标记的方法,匹配成功返回HandlerMethod对象给前端控制器,HandlerMethod对象中封装url对应的方法Method。
RequestMappingHandlerAdapter
注解式处理器适配器,对标记@ResquestMapping的方法进行适配。
说明
在springmvc的各个组件中,处理器映射器、处理器适配器、视图解析器称为springmvc的三大组件。
需要用户实现的组件有handler、view 即Controller和jsp页面。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
浅谈Java程序员职业规划心路
一、构建完整的知识体系 俗话说:学无止境,当然这里的学习并不仅仅指书上的知识、还有生活中、互联网上的。知识广义上来讲可以分为五类:数据、信息、知识、才能和智慧。数据经过整理变成信息,信息能解决某个问题就是知识,知识通过反复实践形成才能,才能融会贯通就是智慧,构建知识体系可以帮助我们提升,在任何情况下稳定高质量的输出,可以更高效地解决遇到的问题,让我们更少的依赖运气,能力水平越高,运气带来的影响就越小,对自己表现的可控比例也就越高。 文末有一些免费的分享,有兴趣的可以去看看。 对知识进行模块化管理,最好的方式是用思维导图把这些底层理论或方法论整理出来,形成一个又一个的知识模块,这样面对类似现象层面的问题时就完全可以把对应知识模块搬出来解决,面对复杂问题时就用多个知识模块。 现在获取知识的途径也很多,可以百度搜索,请教在某方面比较熟悉的同事、朋友,买一些专业的书籍,阅读官方文档等。 我们每个人都会有很多的位置领域,可以每年制订一个的读书计划,年初的时候按照下面的四象限方法列个读书清单,按一定比例去了解自己陌生的领域,扩宽自己的眼界,不做井底之蛙。 二、合理安排自己的时间 1.每天提前一小时...
- 下一篇
业务开发的思考与提升
业务开发:永远被业务驱使或者强奸,越来越忙,支持业务越来越疲于奔命。产品、业务上线快,bug也很多。 这可能是大多数业务开发的写照吧,换了份工作之后,自己也是一直在写业务相关的东西,想说说最近业务开发的经历 每天都在做什么 经常做的是熟悉需求、梳理业务、新的,旧的系统功能点、讨论、写代码。而写业务代码,基本上用到的都是公司封装好的框架,使用起来简化了很多开发步骤,并且根基本上是参照之前代码的写法。 熟悉需求,肯定要做新功能啊,但是新功能从最老大的哪里提出来,产品梳理好之后告诉我们,开发不在第一线,产品与开发各自分工,文档给了开发,要做功能,只有梳理需求,需求文档基本上在整个开发过程都用得到。 梳理业务,新员工都要熟悉公司的业务,时间比较久的公司业务复杂,所以需要梳理。 新、旧系统功能点,也在和梳理业务,需求有很密切的关系,旧系统的功能是超级多的,有需要的都要看。新功能要理 讨论,需求宣讲会,功能点讨论,设计方案讨论等, 完全取决于会议是否高效 写代码,比重不是很大,但一切都要落实到代码上,写代码才能实现需求啊。 总的感觉,不是像网上传的天天码代码,熬夜加班, 这里基本不存在。反而觉得写...
相关文章
文章评论
共有0条评论来说两句吧...