Django+React全栈开发:前置知识

创建于:发布于:文集:Django+React全栈开发

前言

这篇文章来简要讲一下在后续开发工作中可能碰到的一些概念,我会尽量将这些概念讲得易于理解,并列出一些我认为比较好的学习资源,以尽量避免读者在以后碰到这些概念时茫然无措。

当然我也并不是什么权威人士,本文的内容都是建立在目前我的认知基础上的,难以避免会有谬误之处,如果需要深入了解,还是要多多查资料,并在实践中消化。

正文

互联网时代的程序

在互联网时代,如果不考虑游戏,好像人们日常生活中完全不需要网络的软件很少。相信大家至少都用Python写过一些简单的小脚本,这些程序仅仅运行在我们自己的电脑上,不需要和其他人交流,甚至只是做些简单的计算便运行结束。当然人人都有社交的需求,计算机也要谈恋爱(划掉,目前我们接触的软件基本都是网络程序了。当然,虽然都是通信,但是互联网并不是像人们面对面聊天一样的直接,要深入了解建议多搜索计算机网络相关内容。

C/S

Client-Server:客户端-服务端架构。这个相信大家都很熟悉,例如常用的QQ微信,使用这类程序我们要在电脑或手机上安装它们的客户端,这个客户端程序会和它们各自的服务端程序通信,如果我们要用QQ发个消息给朋友,那么通常是这个消息经过我们的客户端发送到腾讯的服务端,再由服务端发送给朋友的客户端。当然这个过程并不是像嘴上说的发送接收那么简单啦。要注意这个客户端可不一定是只有GUI,也就是有图形用户界面的程序才是客户端,很多客户端程序可能你并不能直接看到。

B/S

Browser-Server:浏览器端-服务端架构。这个大家想必更熟悉,平时浏览的各种网站,都是这种模式。有人认为网站不能算是计算机程序,对此我不能表示认同。

对比

接下来说说我对这两种模式的理解。不知道为什么有些人认为C/SB/S是并列关系的两种不同东西。我认为事实上B/S属于C/S。试想,我们用浏览器去浏览一个网站,事实上这个浏览器不就是客户端程序吗?只不过无数的网站服务端都共享浏览器这么一个客户端而已。

我认为所谓B/S不过是一种特殊的C/S罢了,那么这么做有什么好处呢?想一想,大家是否有经常要更新手机上的软件的需求,例如QQ,往往腾讯做出来了新功能,那么就要用户更新一下客户端,而通过浏览器访问的网站,只要浏览器支持它的前端功能,那么往往用户什么都不用做,就能体验到新功能了。

随着互联网的发展,网速越来越快,延迟越来越低,有人甚至提出将应用都放在云端,例如让手机变成一个大型浏览器,手机上只负责展示内容,这样对手机配置的要求也转移到对网速的需求上了。当然现在的网络速度还不够快,我曾经玩过云游戏,可以直接在配置一般的电脑上玩大型游戏,不过现在体验还并不是很好。微信的小程序功能,也体现了这种思想,很多简单的应用,并不需要在我们的手机上再安装一个单独的app

Web Server

通信协议

通信协议是一个很重要的东西,它规定了计算机之间应该怎样通信,如果没有协议,那么就是鸡同鸭讲,互联网也无从谈起了

例如人与人之间交流,我们知道我们的语言的语法规则,知道某个词在句子中的意思,这是使用同样语言的人都知道的规定,我们可以将大脑中的信息,编码成声音信号发出去,而听话的人,则也懂得将这个声音信号解码成大脑能理解的信息。而一只鹦鹉,虽然它也能接收到我们发出的声音信号,但是它不懂我们的语法规则,永远只能学舌,却不能和我们交流。

B/S架构的程序中,基本上是基于HTTP这个协议来通信。建议TCP/IPHTTP协议要重点去了解。

网络服务器

在这里服务器不单单指一类计算机硬件,事实上网络服务器是软硬件一体的,只有一台计算机没有软件你什么也做不了,只有软件没有运行环境也是这样

请求与响应

一个HTTP服务器程序主要需要接收来自客户端的请求以及根据这个请求做出相应的响应

Basic representation of a client/server connection through HTTP

例如你去访问a.com这个网站,服务器将根据你的GET请求,返回一个响应,这其中包含了这个网站首页的HTML文件,浏览器就会把这个页面呈现给你了。还有非常常见的一个响应是当你请求一个并不存在的资源时,你会得到一个404响应

静态服务器与动态服务器

静态服务器并不是说响应的内容渲染出来是静态页面,而是将服务器上的资源原汁原味的传递给你。

动态服务器则不同,动态服务器通常会包含数据库,在经由静态服务器将资源呈现给你之前,还会动态地根据数据库内容对资源做更新

Web框架

这个很好理解,框架就是一个帮你省事的工具,从头开发一套系统非常麻烦,前人种树,后人乘凉,使用Web框架帮助你快速开发,节省时间。Django就是一个非常不错的Web框架。

架构模式

MVC模式

MVC是ModelViewController的缩写。分别代表模型视图控制

例如我们在博客上写一篇文章,看到的网页是视图层的内容,我们写好文章,点击发布按钮,这时控制层根据点击发布按钮这个操作,决定把用户输入的数据,拿去要求模型层存储数据,我们点击一篇文章的链接,控制层则根据这个请求从模型层取出这个文章的数据,转给视图层处理,让我们看到

此外还有MVPMVVM模式,可以查查资料去了解,不过这种东西我觉得不实际运用很难真正理解。

Django的MTV模式

在上一篇文章中,我们已经初步涉及了Django的MTV模式,事实上这是对DjangoMVC模式的一种实现,看过很多文章任务Django中的View就是MVC的控制层,而Template模板层则是视图层,我觉得这是不对的。其实Django的视图层模板层都是决定如何展示给用户数据的部分,可以说都是MVC中的视图层Django官方表示事实上整个Django自身就是控制层。

回到我之前举的写文章的例子,我认为,关于DjangoMTV的到底分别代表MVC中的什么的分歧点在于,视图层到底决不决定如何展现内容。起码Django认为应该这样。而控制层实质上由DjangoURL分发器来实现的,它通过不同的URL请求,去决定调用不同的ViewView再去操控不同的Template

前端与后端

HTML CSS JavaScript

这三样东西基本上是一个网站必不可少的。

前面我提到B/S只是一种特殊的C/S,那么浏览器这个客户端根据什么来让各种各样的网页看上去不一样,功能也不一样呢?

建议去MDN系统学习,不过由于某些历史原因,JavaScript学习起来有点难受(老实说刚刚接触这门语言的时候我觉得这就是坨屎,逃),要加油哦。

前后端分离

之前在Django中使用了模板语言,传统开发模式下,页面处理逻辑,页面的渲染实际上部分是由后端负责的,或者说前后端的分界线比较模糊的,前后端分离的开发模式,分离了关注点,两端可以分别开发调试,大大提升了开发效率,为了做到这一点,我们就不能再使用之前模板的方式。

RESTful API

REST(Representational State Transfer)表现层状态转换。这个名字其实很直观,例如我们博客应用中的文章,可能实际的资源是一串字符串,但是当呈现到表现层时,我们可以将它变成txt文件,HTML或者JSON。也就是说,服务端的资源,在客户端拿到前,发生了状态的转换。因为HTTP协议是无状态协议,客户端通过不同的HTTP请求,让服务端将原始资源转换成不同状态响应回来。

RESTful API有个重要的概念是URI(Uniform Resource Identifier)统一资源标识符,这应该是名词而不是动词。例如,博客中的文章,访问它的URI可以是article,如www.api.blog.com/article/,而不应该是get-articlecreate-articleupdate-articledelete-article,要实现获取、创建、修改、删除操作,只需要客户端发送对应的HTTP请求就行(分别为GET,POST,PUT,DELETE)。统一资源标识符只应表示资源本身。

Django利用Django REST framework这个库可以实现这一点,后续将重点介绍这个库。前后端分离开发也可以基于此实现,前端与后端约定好接口,通过JSON做数据交换。

推荐文章

开始造轮子吧

其实个人做一个博客根本不需要前后端分离开发模式,甚至根本都不需要写代码,完全有直接可用的应用

这里还是要表达一下我的主要想法:学习时多造轮子,工程中多用轮子。也就是学习的时候能怎么折腾怎么折腾,实际生产生活的时候则尽量应用成熟的已有的应用。

EOF
Github
Copyright © 2020-2024 Elliot