Web开发的历史发展技术演变

一、简单明快的早期时代,二、后端为主的 MVC 时代,三、Ajax 带来的 SPA 时代,四、前端为主的 MV* 时代,五、Node 带来的全栈时代

一、简单明快的早期时代

Web 1.0 时代,非常适合创业型小项目,不分前后端,经常 3-5 人搞定所有开发。

页面由 JSP、PHP 等工程师在服务端生成,浏览器负责展现。基本上是服务端给什么浏览器就展现什么,展现的控制在 Web Server 层。

好处是:简单明快,本地起一个 Tomcat 或 Apache 就能开发,调试什么的都还好,只要业务不太复杂。

坏处是: 1.想调整下按钮样式,却要本地开发、代码上传、验证生效等好几个步骤。前端开发难以本地化

             2.JSP 等代码的可维护性越来越差。积攒到一定阶段时,往往会带来大量维护成本。

二、后端为主的 MVC 时代

3.jpg

为了降低复杂度,以后端为出发点,有了 Web Server 层的架构升级,比如 Structs、Spring MVC 等,这是后端的 MVC 时代。

这种架构下,前后端协作有两种模式:

一种是前端写 demo,写好后,让后端去套模板。

另一种协作模式是前端负责浏览器端的所有开发和服务器端的 View 层模板开发,支付宝是这种模式。

好处: 代码可维护性得到明显好转,MVC 是个非常好的协作模式,从架构层面让开发者懂得什么代码应该写在什么地方。

坏处: 前端开发重度依赖开发环境。前后端职责依旧纠缠不清。

Velocity 模板还是蛮强大的,变量、逻辑、宏等特性,依旧可以通过拿到的上下文变量来实现各种业务逻辑。在模板层写出不少业务代码。

Controller,页面路由等功能本应该是前端最关注的,但却是由后端来实现

Controller 本身与 Model 往往也会纠缠不清。Controller会产生大量代码,变得很臃肿。

三、Ajax 带来的 SPA 时代

2004 年 Gmail 像风一样的女子来到人间,很快 2005 年 Ajax 正式提出,加上 CDN 开始大量用于静态资源存储,于是出现了 JavaScript 王者归来的 SPA (Single Page Application 单页面应用)时代。

这种模式下,前后端的分工非常清晰,前后端的关键协作点是 Ajax 接口。在此基础上形成了前后端分离,形成  resful 等架构

类似 Spring MVC,这个时代开始出现浏览器端的分层架构这之后为前端 mvvm 模式提供了基础

5.jpg

问题:

1.前后端接口的约定。 之后有 API Blueprint 等方案

2.前端开发的复杂度控制。产生大量的JavaScript 代码  

四、前端为主的 MV* 时代

6.jpg

为了降低前端开发复杂度大量框架涌现。

好处:

1.前后端职责很清晰。前端工作在浏览器端,后端工作在服务端。清晰的分工,可以让开发并行,测试数据的模拟不难,前端可以本地开发。后端则可以专注于业务逻辑的处理,输出 RESTful 等接口。

2.前端开发的复杂度可控。前端代码很重,但合理的分层,让前端代码能各司其职。这一块蛮有意思的,简单如模板特性的选择,就有很多很多讲究。并非越强大越好,限制什么,留下哪些自由,代码应该如何组织,所有这一切设计,得花一本的厚度去说明。

3.部署相对独立,产品体验可以快速改进。

不足之处:

1.代码不能复用。比如后端依旧需要对数据做各种校验,校验逻辑无法复用浏览器端的代码。

2.全异步,对 SEO 不利。往往还需要服务端做同步渲染的降级方案。   性能并非最佳,特别是移动互联网环境下。

3.SPA 不能满足所有需求,依旧存在大量多页面应用。

4.URL Design 需要后端配合

五、Node 带来的全栈时代 (探索)

7.png

随着 Node.js 的兴起,JavaScript 开始有能力运行在服务端。这意味着可以有一种新的研发模式

在这种研发模式下,前后端的职责很清晰。对前端来说,两个 UI 层各司其职:

1、Front-end UI layer 处理浏览器层的展现逻辑。通过 CSS 渲染样式,通过 JavaScript 添加交互功能,HTML 的生成也可以放在这层,具体看应用场景。

2、Back-end UI layer 处理路由、模板、数据获取、cookie 等。通过路由,前端终于可以自主把控 URL Design,这样无论是单页面应用还是多页面应用,前端都可以自由调控。后端也终于可以摆脱对展现的强关注,转而可以专心于业务逻辑层的开发。

通过 Node,Web Server 层也是 JavaScript 代码,这意味着部分代码可前后复用,需要 SEO 的场景可以在服务端同步渲染,由于异步请求太多导致的性能问题也可以通过服务端来缓解。前一种模式的不足,通过这种模式几乎都能完美解决掉。

坏处:

1、需要前端对服务端编程有更进一步的认识。比如 network/tcp、PE 等知识的掌握。

2.Node 层与 Java 层的高效通信。Node 模式下,都在服务器端,RESTful HTTP 通信未必高效,通过 SOAP 等方式通信更高效。

3.一切需要在探索验证中前行。

参考https://blog.csdn.net/alitech2017/article/details/108200495?utm_medium=distribute.pc_feed.none-task-blog-personrec_tag-12.nonecase&depth_1-utm_source=distribute.pc_feed.none-task-blog-personrec_tag-12.nonecase&request_id=5f4427720388ae0b5643d643

猜你喜欢

转载自blog.csdn.net/qq_33253054/article/details/108241165
今日推荐