全栈工程师修炼指南
熊燚(四火)
Oracle首席软件工程师
立即订阅
2286 人已学习
课程目录
已更新 43 讲 / 共 40 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 从成长角度看,为什么你应该成为全栈工程师?
免费
学习路径 | 怎样成为一名优秀的全栈工程师?
导读 | 如何学习这个专栏?
第一章 网络协议和 Web 接口 (6讲)
01 | 网络互联的昨天、今天和明天:HTTP 协议的演化
02 | 为HTTP穿上盔甲:HTTPS
03 | 换个角度解决问题:服务端推送技术
04 | 工整与自由的风格之争:SOAP和REST
05 | 权衡的艺术:漫谈Web API的设计
06 | 特别放送:北美大厂如何招聘全栈工程师?
第二章 欢迎来到 MVC 的世界 (7讲)
07 | 解耦是永恒的主题:MVC框架的发展
08 | MVC架构解析:模型(Model)篇
09 | MVC架构解析:视图(View)篇
10 | MVC架构解析:控制器(Controller)篇
11 | 剑走偏锋:面向切面编程
12 | 唯有套路得人心:谈谈Java EE的那些模式
13 | 特别放送:选择比努力更重要
第三章 从后端到前端 (7讲)
14 | 别有洞天:从后端到前端
15 | 重剑无锋,大巧不工:JavaScript面向对象
16 | 百花齐放,百家争鸣:前端MVC框架
17 | 不一样的体验:交互设计和页面布局
18 | 千言万语不及一幅画:谈谈数据可视化
19 | 打开潘多拉盒子:JavaScript异步编程
20 | 特别放送:全栈团队的角色构成
第四章 数据持久化 (7讲)
21 | 赫赫有名的双刃剑:缓存(上)
22 | 赫赫有名的双刃剑:缓存(下)
23 | 知其然,知其所以然:数据的持久化和一致性
24 | 尺有所短,寸有所长:CAP和数据存储技术选择
25 | 设计数据持久层(上):理论分析
26 | 设计数据持久层(下):案例介绍
27 | 特别放送:聊一聊代码审查
第五章 寻找最佳实践 (6讲)
28 | Ops三部曲之一:配置管理
29 | Ops三部曲之二:集群部署
30 | Ops三部曲之三:测试和发布
31 | 防人之心不可无:网站安全问题窥视
32 | 和搜索引擎的对话:SEO的原理和基础
33 | 特别放送:聊一聊程序员学英语
第六章 专题 (7讲)
34 | 网站性能优化(上)
35 | 网站性能优化(下)
36 | 全栈开发中的算法(上)
37 | 全栈开发中的算法(下)
38 | 分页的那些事儿
39 | XML、JSON、YAML比较
40 | 全栈衍化:让全栈意味着更多
全栈工程师修炼指南
登录|注册

10 | MVC架构解析:控制器(Controller)篇

四火 2019-10-02
你好,我是四火。
今天我们继续学习 MVC 架构,主要内容就是 MVC 架构的第三部分——控制器(Controller)。
控制器用于接收请求,校验参数,调用 Model 层获取业务数据,构造和绑定上下文,并转给 View 层去渲染。也就是说,控制器是 MVC 的大脑,它知道接下去该让谁去做什么事。控制器层是大多数 MVC 框架特别愿意做文章的地方,我相信你可能耳闻、了解,甚至熟练使用过一些 MVC 框架了。
那么与其去抽象地学习这一层的重要概念、原理,或是单纯地学习这些框架在这一层略显乏味的具体配置,我想我们今天“不走寻常路”一次,把这两者结合起来——我们来比较 Servlet、Struts 和 Spring MVC 这三种常见的技术和 MVC 框架,在控制器层的工作路数,以及和业务代码整合配置的方式,看看任这些框架形式千变万化,到底有哪些其实是不变的“套路”呢?
随着请求到达控制器,让我们顺着接下去的请求处理流程,看看控制器会通过怎样的步骤,履行完它的职责,并最终转到相应的视图吧。

1. 路径映射和视图指向

我们不妨把 MVC 架构的控制器想象成一个黑盒。当 HTTP 请求从客户端送达的时候,这个黑盒要完成一系列使命,那么它就有一个入口路由和一个出口路由:
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《全栈工程师修炼指南》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(7)

  • Mandalorian
    Django使用配置文件,Flask使用装饰器。
    2019-10-03
    1
  • 鹏😎
    1. 配置方式,自己更喜欢通过注解的形式,之前实践过程中就是感觉比较简单,用时直接配置。但今天通过学习老师的课程感觉任何技术都与优势和劣势,对于配置方式,最大的缺点就是路径映射分散,难于统一管理,后期维护起来比较麻烦,以后项目要多注意这块。
    2. 接口调用:controller收到请求,验参,将请求转化为内部服务调用,同步反馈处理结果或者异步回掉结果,视图请求:请求,验参,服务调用,返回视图。

    四火老师后续的客户是否包含前后端分离技术?

    作者回复: 前面说得挺好,最后的问题没有看懂。

    2019-10-12
  • Paradise丶朽木
    选修课堂补充我自己遇到的两个问题:
    1. win10 环境下编辑java文件,环境变量那里替换成 $env:CATAIINA_HOME(powershell)
    2. Tomcat启动之后页面报错500(javax.servlet.ServletException: Error instantiating servlet class [com.xxx.BookServlet]),配置web.xml时,servlet-class 只保留类名就可以了

    作者回复: 👍

    2019-10-10
  • 不记年
    平时更多的是配置和注解混用的方式,配置多用于宏观一点的东西,例如控制器的注册。注解更偏向于微观一点,例如参数绑定
    2019-10-10
  • leslie
    MVC这块知识对于早期做面向过程开发的而言只能慢慢的循环啃了、、、本来以为不用再碰这些,绕了一圈发现不懂还是不行,不过啃起来确实蛮辛苦
    2019-10-10
  • pyhhou
    1. 更喜欢把配置放在单独一层,这么做的好处是部署的时候,更改配置比较方便而且基本不会有遗漏。这里不知道是不是可以使用二者结合的方式,对于那些经常变的配置,比如 IP 地址,端口号,token,数据库连接可以考虑放在单独一层,其他和具体业务逻辑相关的,不容易改变的配置,利用注解和实现逻辑放在一起

    2. 控制层基本上就做数据验证、然后 mapping 到对应的业务处理函数,业务处理函数处理好请求后会将结果返回,控制层将业务处理函数返回的结果作为响应返回给前端页面

    选修课堂的例子,web.xml 和 BookSevlet.java 所做的事情都属于 controller 层的范畴,book.jsp 里面对应的是 Model 层和 view 层,因为使用了 JavaBean 这里应该算是 View 去直接接触 Model?

    作者回复: 👍

    2019-10-09
  • anginiit
    思考题:
    1: 我更喜欢把配置和业务放到一起,因为这样更直接,我可以直接对应到控制层方法,查错也更直接一些,在工作中很少去查看所有路由的。
    2:现在的项目都在使用springmvc,控制层很简单,只是去请求服务层,在一些特殊的情况下会有一些校验逻辑。

    作者回复: 👍

    2019-10-08
收起评论
7
返回
顶部