对前后端分离设计模式的理解总结(部分Django描述)

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了对前后端分离设计模式的理解总结(部分Django描述)相关的知识,希望对你有一定的参考价值。

参考技术A

FBV:Function base view 基于方法的视图

CBV:Class base view 基于类的视图

所以之后我了解到,其实是我没有了解 FBV 与 CBV 的概念。

正所谓:类就是 把数据封装进对象里 ,并赋予对象 行为 的能力。

所以我们完全可以把一个需求的接口封装成为一个类:

因为继承了 django 的 View 类,所以在默认情况下,会自动根据请求类型映射该类中对应的请求方法。

但是在所有的 python web 框架乃至一些其他语言的框架之中,对 HTTP 请求类型的方法映射都是由一个专门的反射函数来实现的

所以, 总结如下:

另外值得一提的是:自己那个类中的 dispatch 方法中如果不自己去映射而是调用父类(django 的 View)的 dispatch 方法,另外还在前后做一些附加操作,这样的功能跟 “ 装饰器 ” 就很相似了。

一共有10个项目,那让我们一起来慢慢学习吧!

300 系列:重定向类

400 系列 :客户端错误

500 系列: 服务端错误

前后端分离方案以及技术选型

参考技术A

作者:关开发

一.什么是前后端分离?

理解前后端分离大概可以从3个方面理解:

1. 交互形式

2. 代码组织形式

3. 开发模式与流程

1.1 交互形式

前后端不分离

后端将数据和页面组装、渲染好了之后,向浏览器输出最终的html;浏览器接收到后会解析html,解析引入的css、执行js脚本,完成最终的页面展示。

前后端分离

后端只需要和前端约定好接收以及返回的数据格式(一般用JSON格式),向前端提供API接口。前端就可以通过HTTP请求调用API的方式进行交互。前端获取到数据后,进行页面组装、渲染,最终在浏览器呈现。

1.2 代码组织形式

前后端不分离

在web应用早期的时候,前端页面以及后台业务数据处理的代码都放在一个工程下,甚至放在同一目录下,前端页面夹杂着后端代码。前、后端开发工程师都需要把整套代码导入开发工具才能开发。此阶段下前后端代码以及工作耦合度太高,前端不能独立开发和测试,后端人员也要依赖前端完成页面后才能完成开发。最糟糕的情况是前端工程师需要会后端模板技术(jsp),后端工程师还要会点前端技术,需要口头说明页面数据接口,才能配合完成开发。否则前端只能当一个“切图仔”,只输出HTML、CSS、以及很少量与业务逻辑无关的js;然后由后端转化为后端jsp,并且还要写业务的js代码。

前后端分离

前后端代码放在不同的工程下,前端代码可以独立开发,通过mock/easy-mock技术模拟后端API服务可以独立运行、测试;后端代码也可以独立开发,运行、测试,通过swagger技术能自动生成API文档供前端阅读,还可以进行自动化接口测试,保证API的可用性,降低集成风险。

1.3 开发模式与流程

前后端不分离

在项目开发阶段,前端根据原型和UI设计稿,编写HTML、CSS以及少量与业务无关的js(纯效果那些),完成后交给后台人员,后台人员将HTML转为jsp,并通过JSP的模板语法进行数据绑定以及一些逻辑操作。后台完成后,将全部代码打包,包含前端代码、后端代码打成一个war,然后部署到同一台服务器运行。顶多做一下动静分离,也就是把图片、css、js分开部署到nginx。

具体开发流程如下:图略

前后端分离

实现前后端分离之后,前端根据原型和UI设计稿编写HTML、CSS以及少量与业务无关的js(纯效果那些),后端也同时根据原型进行API设计,并与前端协定API数据规范。等到后台API完成,或仅仅是API数据规范设定完成之后。前端即可通过HTTP调用API,或通过mock数据完成数据组装以及业务逻辑编写。前后端可以并行,或者前端先行于后端开发了。

具体开发流程如下:图略

二、前后端分离的好处与坏处。

从上面3个方面对比了之后,前后端分离架构和传统的web架构相比,有很大的变化,看起来好处多多。到底是分还是不分,我们还是要理性分析是否值得才去做。

从目前应用软件开发的发展趋势来看,主要有两方面需要注意:

· 越来越注重用户体验,随着互联网的发展,开始多终端化。

· 大型应用架构模式正在向云化、微服务化发展。

我们主要通过前后端分离架构,为我们带来以下四个方面的提升:

· 为优质产品打造精益团队

通过将开发团队前后端分离化,让前后端工程师只需要专注于前端或后端的开发工作,是的前后端工程师实现自治,培养其独特的技术特性,然后构建出一个全栈式的精益开发团队。

· 提升开发效率

前后端分离以后,可以实现前后端代码的解耦,只要前后端沟通约定好应用所需接口以及接口参数,便可以开始并行开发,无需等待对方的开发工作结束。与此同时,即使需求发生变更,只要接口与数据格式不变,后端开发人员就不需要修改代码,只要前端进行变动即可。如此一来整个应用的开发效率必然会有质的提升。

· 完美应对复杂多变的前端需求

如果开发团队能完成前后端分离的转型,打造优秀的前后端团队,开发独立化,让开发人员做到专注专精,开发能力必然会有所提升,能够完美应对各种复杂多变的前端需求。

· 增强代码可维护性

前后端分离后,应用的代码不再是前后端混合,只有在运行期才会有调用依赖关系。应用代码将会变得整洁清晰,不论是代码阅读还是代码维护都会比以前轻松。

那么前后端分离有什么不好的地方吗?我目前是没有想到,除非你说会增加前端团队的配备,后端工程师会变的不全能。。。

二、前后端分离架构方案。

实现前后端分离,主要是前端的技术架构变化较大,后端主要变为restfull 风格API,然后加上Swagger技术自动生成在线接口文档就差不多了。

对于目前用于前后端分离方案的前端技术架构主要有两种:

· 传统SPA

· 服务端渲染SSR

2.1 传统SPA

传统SPA指的是单页面应用,也就是整个网站只有一个页面,所有功能都通过这一个页面来呈现。因为一个人的肉眼,某一个时间点看一个页面,既然如此何必要不同功能做多个页面呢?只保留一个页面作为模板,然后通过路由跳转来更新这个模板页面的内容不就可以了吗?确实如此,现在通过reac全家桶、tvue全家桶,模块化、路由、wabpack等技术轻而易举就能实现一个单页面应用。

单页面应用的运行流程

1.用户通过浏览器访问网站url

2.单页面的html文件(index.html)被下载到浏览器,接着下载html里面引用的css,js。

3.css,js下载到浏览器完成之后,浏览器开始解析执行js向后端服务异步请求数据。

4.请求数据完成后,进行数据绑定、渲染,最终在用户浏览器呈现完整的页面。

2.2 服务端渲染

服务端渲染的方案指的是数据绑定,渲染等工作都放在服务端完成,服务端向浏览器输出最终的html。大家看完这个是不是有个疑问,这不是又回到了前后端不分离的时代了吗?答案是否定的,因为这里的服务端是用来执行前端数据绑定、渲染的,也就是把浏览器的一部分工作分担到了服务端。而目前具备这只种能力的服务端是NodeJs服务端。

它的原理其实就是在浏览器与前端代码中间插入了一个NodeJs服务端。浏览器请求前端页面时,会先经过NodeJS服务端,由NodeJs去读取前端页面,并执行异步后端API,获取到数据后进行页面数据绑定,渲染等工作,完成一个最终的html然后返回浏览器,最后浏览器进行展示。

服务端渲染应用的运行流程:

1.用户通过浏览器访问网站url

2.NodeJS服务端接收到请求,读取到对应的前端html,css,js。

3.NodeJS解析执行js向后端API异步请求数据。

4.NodeJs请求数据完成之后,进行数据绑定、渲染,得到一个最终的html。

5.NodeJs向浏览器输出html,浏览器进行展示。

PS:其实本质就是把前端编写成一个nodeJs的服务端web应用。实施服务端渲染后,我们最终运行的是一个Nodejs服务端应用。而单页面应用是把静态页面部署到静态资源服务器进行运行。

看到这里,你是否又有疑问,为什么要这么麻烦搞服务端渲染呢?

2.3 SPA与服务端渲染方案对比

SPA的优点是开发简单,部署简单;缺点是首次加载较慢,需要较好的网络,不友好的SEO。

so,以下就是使用服务端渲染的理由了(摘取vue官方说法):

与传统 SPA (单页应用程序 (Single-Page Application)) 相比,服务器端渲染 (SSR) 的优势主要在于:

· 更好的 SEO,由于搜索引擎爬虫抓取工具可以直接查看完全渲染的页面。

请注意,截至目前,Google 和 Bing 可以很好对同步 JavaScript 应用程序进行索引。在这里,同步是关键。如果你的应用程序初始展示 loading 菊花图,然后通过 Ajax 获取内容,抓取工具并不会等待异步完成后再行抓取页面内容。也就是说,如果 SEO 对你的站点至关重要,而你的页面又是异步获取内容,则你可能需要服务器端渲染(SSR)解决此问题。

· 更快的内容到达时间 (time-to-content),特别是对于缓慢的网络情况或运行缓慢的设备。

无需等待所有的 JavaScript 都完成下载并执行,才显示服务器渲染的标记,所以你的用户将会更快速地看到完整渲染的页面。通常可以产生更好的用户体验,并且对于那些「内容到达时间(time-to-content) 与转化率直接相关」的应用程序而言,服务器端渲染 (SSR) 至关重要。

使用服务器端渲染 (SSR) 时还需要有一些权衡之处:

· 开发条件所限。浏览器特定的代码,只能在某些生命周期钩子函数 (lifecycle hook) 中使用;一些外部扩展库 (external library) 可能需要特殊处理,才能在服务器渲染应用程序中运行。

· 涉及构建设置和部署的更多要求。与可以部署在任何静态文件服务器上的完全静态单页面应用程序 (SPA) 不同,服务器渲染应用程序,需要处于 Node.js server 运行环境。

· 更多的服务器端负载。在 Node.js 中渲染完整的应用程序,显然会比仅仅提供静态文件的 server 更加大量占用 CPU 资源 (CPU-intensive - CPU 密集),因此如果你预料在高流量环境 (high traffic) 下使用,请准备相应的服务器负载,并明智地采用缓存策略。

以vue为例,实施服务端渲染可以查看官方指南: https://ssr.vuejs.org ,或选择Nuxt.js

2.4 预渲染技术

如果你调研服务器端渲染 (SSR) 只是用来改善少数营销页面(例如 /, /about, /contact 等)的 SEO,那么你可能需要预渲染。无需使用 web 服务器实时动态编译 HTML,而是使用预渲染方式,在构建时 (build time) 简单地生成针对特定路由的静态 HTML 文件。优点是设置预渲染更简单,并可以将你的前端作为一个完全静态的站点。

如果你使用 webpack,你可以使用 prerender-spa-plugin 轻松地添加预渲染。它已经被 Vue 应用程序广泛测试 - 事实上,作者是 Vue 核心团队的成员。

prerender-spa-plugin: https://github.com/chrisvfritz/prerender-spa-plugin

三、前后端分离技术选型

- artTemplate + bootstrap(不推荐, 不算完全前后端分离)

- vue全家桶(推荐)

- react全家桶 (推荐,生态全)

以上是关于对前后端分离设计模式的理解总结(部分Django描述)的主要内容,如果未能解决你的问题,请参考以下文章

前后端分离的架构设计分析

前后端分离方案以及技术选型

前端经典面试题前后端分离(说一说你理解的前后端分离?)

django 开发之前后端分离开发模式

前后端分离后台api接口框架探索

django前后端分离与不分离概念