全栈工程师修炼指南
熊燚(四火)
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 | 全栈衍化:让全栈意味着更多
全栈工程师修炼指南
登录|注册

09 | MVC架构解析:视图(View)篇

四火 2019-09-30
你好,我是四火。
今天我们继续学习 MVC 架构,主要内容就是 MVC 架构的第二部分——视图(View)。

概念

首先,我想问一问,什么是视图?有程序员说是界面,有程序员说是 UI(User Interface),这些都对,但是都不完整。
我认为 MVC 架构中的视图是指将数据有目的、按规则呈现出来的组件。因此,如果返回和呈现给用户的不是图形界面,而是 XML 或 JSON 等特定格式组织呈现的数据,它依然是视图,而用 MVC 来解决的问题,也绝不只是具备图形界面的网站或者 App 上的问题。

页面聚合技术

虽然视图的定义实际更宽泛,但是我们平时讲到的视图,多半都是指“页面”。这里,就不得不提花样繁多的页面聚合技术了。
回想一下,之前我们在讲 Model 层的时候,是怎样解耦的?我们的办法就是继续分层,或是模块化;而对于 View 层来说,我们的办法则是拆分页面,分别处理,最终聚合起来。具体来说,这里提到的页面聚合,是指将展示的信息通过某种技术手段聚合起来,并形成最终的视图呈现给用户。页面聚合有这样两种典型类型。
结构聚合:指的是将一个页面中不同的区域聚合起来,这体现的是分治的思想。例如一个页面,具备页眉、导航栏、目录、正文、页脚,这些区域可能是分别生成的,但是最后需要把它们聚合在一起,再呈现给用户。
数据 - 模板聚合:指的是聚合静态的模板和动态的数据,这体现的是解耦的思想。例如有的新闻网站首页整个页面的 HTML 是静态的,用户每天看到的样子都是差不多的,但每时每刻的新闻列表却是动态的,是不断更新的。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《全栈工程师修炼指南》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(11)

  • CC
    1. 用过 SSI 和 Nunjucks。

    当时选择 SSI 是因为自己对前端技术了解不足,SSI 容易掌握。当对复杂模板有需求后,找到了 Nunjucks。

    现在回头看,其实自己对模板引擎的 trade-off 了解并不多,拿到一个就用,缺少深入理解。


    2. 我不同意这个观点。

    客户端聚合有代价。

    第一次进入 web 或 web app 要等待一段时间。如果手机+不流畅的网络访问,一开始的体验不太好。如果是复杂的 web app,那么客户端需要下载的文件量和计算量就较大,等待时间就更长。

    如文中提到,服务端聚合,可以通过分层和解耦,把一部分信息优先发送到客户端,这样会有更好的体验。

    还有一种选择是 static site generator,把聚合的步骤在本地完成。但它不适合需要动态更新的网站,以及如果网站数据很大,本地编辑和执行的时间就会很长。

    根据具体需求,选择适合的方案。

    作者回复: 👍

    2019-10-01
    1
  • 💢 星星💢
    原来公司项目用的template是这个原因啊,我说为啥不直接用jsp el取值呢,哈哈。。
    2019-11-26
  • 鹏😎
    小白,努力学习中...
    2019-10-11
  • leslie
    打卡吧:欠账了、、、开发的东西确实学习中结合面向模块编程在啃理解-发现确实还是理解起来很辛苦,放慢学习速度慢慢循环去看才能大致明白;后面加紧吧,坚持在课程完成的时能把每篇文章基本学完。
    2019-10-09
  • leslie
    都没用过:补课去😂😂😂怪不得感觉现在开发DEV+CSS的结构基本消失甚至很多UI和前端开发都不会这种架构。
    2019-10-08
  • pyhhou
    1. 之前在用 React 的时候使用过一个叫 JSX 的东西,其功能就是将 HTML 样式的代码转化成 JavaScript 中的函数调用,对于一些复杂的结构,JSX 可以让代码变得更加简洁清晰,使得 React 中的代码风格能够被大多数人所适应,一开始认为 JSX 就是模版引擎,毕竟直观看,它和模版引擎的功能极其相似,但是 JSX 并不是模版引擎,只是用来代替模版引擎的一个语法糖,解释就是 JSX 表达的是 Virtual DOM 并不是实际的 HTML;之前之所以选用这个技术也是看 React 官网上说 JSX 和 React 比较搭

    2. 不是特别同意这个观点,老师在文章中已经提到了客户端聚合的一些缺陷,就是这种方式需要客户端有一定的规范性和运算处理能力,如果是仅仅使用客户端聚合而不考虑服务器端聚合,这等同于将鸡蛋放在同一个篮子里,当项目的规模上来了,页面的模块增多了,聚合的复杂性将大大提升,客户端聚合将不能很好的进行;个人认为正确的考虑方式是结合实际情况考虑,将复杂的任务拆分并解耦,综合考虑服务器端聚合和客户端聚合

    作者回复: 👍

    2019-10-08
  • 易儿易
    那jsp就属于服务端聚合了呗,毕竟编译后的servlet控制生成html并且运行在服务器上,现在一直在开发维护老项目使用陈旧的flex,应该是客户端聚合,客户端下载编译好的swf,请求完数据后聚合在页面内
    2019-10-07
  • 丁丁历险记
    我的天,硬是听出玄幻小说等更新的感觉。。。

    作者回复: 😝

    2019-09-30
  • 靠人品去赢
    模板引擎好像没有怎么大规模用过,小程序,bootstrap,easyUI用的比较多,拿easyUI举例子感觉更像是iframe的聚合,里面会嵌套两个页面。像微信小程序这种算是模板引擎吗,感觉这种声明式的一般来说模板引擎的面比较大?
    服务端聚合还是要用的,你不要说浏览器的页面,要考虑兼容性。即使现在所谓大前端一把梭的情况,你什么都指望客户端聚合,不要说各种客户端,各种大小适配的问题,感觉做不到啊
    2019-09-30
  • 张理查rootv
    喜欢这种带扩展阅读的方式,节省了很多查找优质信息的时间。
    2019-09-30
  • Mandalorian
    从反爬虫的角度,

    放在客户端聚合,势必要分多个请求。不想暴露的数据api就得引入加解密。

    对于服务端聚合的页面,比较好控制呈现的数据维度和量,爬虫也只能老实的解析dom树。

    作者回复: 想法不错!但是如果只是为了反爬虫,还有其它更好的方法来做到这一点(比如使用随页面生成的一次性 token),而不是说为了反爬虫就必须把 Web API 隐藏起来。

    2019-09-30
    1
收起评论
11
返回
顶部