内容简介:很久以前的web开发是怎么一个工作模式呢?那时候的前端不像现在的前端,那时候的前端基本上就是熟练CSS和HTML就可以了,JS要求其实 也不高,开发流程是这样的,前端先写好静态页面,然后丢给后端来套模板,那么问题来了,如果发现页面上的样式要改怎么办?如果前端水平高,一次性写出无bug代码,那还好说,如果前端水平不行,哈哈哈哈哈哈哈哈,就等着哭吧。那怎么处理用户数据呢?以前流行jQuery,一般是在button上绑定事件,用户提交的时候,jQuery用AJAX向后端发送一个form表单,当然 发送之前前端可
旧石器时代:表单
很久以前的web开发是怎么一个工作模式呢?那时候的前端不像现在的前端,那时候的前端基本上就是熟练CSS和HTML就可以了,JS要求其实 也不高,开发流程是这样的,前端先写好静态页面,然后丢给后端来套模板,那么问题来了,如果发现页面上的样式要改怎么办?
- 方法一:前端到后端的电脑上来改
- 方法二:前端改好之后,后端重新套模板,然后各种渲染
如果前端水平高,一次性写出无bug代码,那还好说,如果前端水平不行,哈哈哈哈哈哈哈哈,就等着哭吧。
那怎么处理用户数据呢?以前流行jQuery,一般是在button上绑定事件,用户提交的时候,jQuery用AJAX向后端发送一个form表单,当然 发送之前前端可能会对数据进行校验,但是无所谓,后端还是要校验,后端一般拿到数据之后,除了校验还要做类型转换。为什么呢?
参考这篇博客 ,我们的form表单传给后端的时候是没有 类型信息的,全都是字符串,所以我们要把取出来的参数做强制转型,此外还要检验参数是否存在等。
所以代码长得有点像这样:
from flask import Flask, request, abort app = Flask(__name__) @app.route("/") def hello(): user_id = request.args.get("user_id") passwd = request.args.get("passwd") if not (user_id and passwd): abort(401) user_id = int(user_id) # 略略略 if __name__ == "__main__": app.run()
因此就有了一个东西,叫做表单校验工具,是啊,谁乐意老是写这么多重复的校验代码,说实话,之前没用过第三方的表单校验,都是 公司内部造的轮子,但是 Python 界还是有一个非常出名的表单校验工具: WTForms , 不过说实话,我没用过,不太好作评价。但是表单校验 工具 长得都差不多:
- 定义好这个参数是否必须
- 定义好这个参数的类型
- 定义好这个参数的要求,例如范围,长度,可否为空等
然后根据定义好的这些用响应的validators进行校验,如果失败就返回错误或者抛出对应的异常。此外,表单校验工具一般都会把form表单 的数据根据所定义好的类型转换成对应的数据。
新的曙光,前后端分离
一直一直一直到了近些年,大前端时代,前后端分离这种架构慢慢流行起来。流行的原因是什么呢?因为移动互联网,没人愿意给前端渲染 一遍模板,又给app开发一套代码,麻烦得要命,所以我们只提供API,前端自己渲染数据。近年来更是有RESTFul啊这些概念,以前写接口 那都是xml来作为传输格式的。
JSON,全名是JavaScript Object Notation,就是把js里的集中基本数据类型,拿出来表示数据,其实这货在Python里可以很好的映射, 例如JSON的array对应Python的List,object对应dict,blablabla。一个简单的JSON长得像这样:
{ "glossary": { "title": "example glossary", "GlossDiv": { "title": "S", "GlossList": { "GlossEntry": { "ID": "SGML", "SortAs": "SGML", "GlossTerm": "Standard Generalized Markup Language", "Acronym": "SGML", "Abbrev": "ISO 8879:1986", "GlossDef": { "para": "A meta-markup language, used to create markup languages such as DocBook.", "GlossSeeAlso": ["GML", "XML"] }, "GlossSee": "markup" } } } } }
像Python这样的动态类型语言写这些可爽了,直接 json.loads
然后开干,但是像 Go 这样的强类型静态语言就不行了,要先定义好
JSON的结构,然后慢慢解析,虽然Go也可以强行解析成一个 interface{}
,但是interface走天下也不是太好。
xml
如果你调用过微信的接口你就会发现,微信接口竟然还用xml。。。xml也是一种数据表现形式,长得跟html有点像,各种tag和嵌套,用来 表示复杂的关系时还可以用用,不过这年头用xml的确实不多了。给个例子你就知道为什么没人愿意用了,上面的JSON的例子,用xml表示 是这样:
<!DOCTYPE glossary PUBLIC "-//OASIS//DTD DocBook V3.1//EN"> <glossary><title>example glossary</title> <GlossDiv><title>S</title> <GlossList> <GlossEntry ID="SGML" SortAs="SGML"> <GlossTerm>Standard Generalized Markup Language</GlossTerm> <Acronym>SGML</Acronym> <Abbrev>ISO 8879:1986</Abbrev> <GlossDef> <para>A meta-markup language, used to create markup languages such as DocBook.</para> <GlossSeeAlso OtherTerm="GML"> <GlossSeeAlso OtherTerm="XML"> </GlossDef> <GlossSee OtherTerm="markup"> </GlossEntry> </GlossList> </GlossDiv> </glossary>
emm...看到都不想碰
对比:模板渲染和前后端分离
最后我们来对比一下模板渲染和前后端分离。模板渲染有什么好处呢?一般来说,模板渲染的性能会高一些,因为模板渲染的原理是, 渲染器把模板文件“编译”成对应的程序,这个程序里的代码就是模板里想表述的代码,然后各种字符串拼接,所以模板实际上最后变成了 程序代码。其实你要是看到很多 Java 程序员写模板,他们还有很多for循环里put一个标签之类的,那就是在手写模板。
而前后端分离性能理论上应该要稍差,因为首先html下发到浏览器之后,浏览器才去获取首页的数据,然后渲染,当然,现在也有用 nodejs在服务器端请求api之后渲染,其实也差不多,总之呢,前后端分离之后,前端和后端请求数据这一步是省不掉的。
既然前后端分离这么灵活,模板渲染有啥好处?第一,容易被爬虫抓到,第二,服务端可以丢到缓存里,这样性能更高。而前后端分离 则恰恰相反,爬虫不一定能抓到,很大程度上要依靠浏览器进行缓存。但是呢,前后端分离大大的解耦了前端 程序员 和后端程序员, 只要约定好了API,各自更改各自的程序,互不影响。
现在我基本不写模板渲染了,哈哈哈。
讲完,收工 :)
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- ABP开发框架前后端开发系列---(14)基于Winform的ABP快速开发框架
- Java开发人员的Flex开发
- Java开发人员的Flex开发
- 行为驱动开发让开发做正确事
- 让开发者专注于应用开发,OpenCenter 3.0 开发者预览版发布
- 让开发者专注于应用开发,OpenCenter 3.0 开发者预览版发布
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
RESTful Web Services Cookbook中文版
Subbu Allamaraju / 丁雪丰、常可 / 电子工业出版社 / 2011-9 / 59.00元
RESTful Web Services Cookbook中文版:REST最佳实践手册,ISBN:9787121143908,作者:(美)Subbu Allamaraju(沙布·阿拉马拉尤)著,丁雪丰,常可 译一起来看看 《RESTful Web Services Cookbook中文版》 这本书的介绍吧!