转载

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

前言

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

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

正文

互联网时代的程序

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

C/S

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

B/S

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

对比

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

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

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

Web Server

通信协议

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

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

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

网络服务器

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

请求与响应

我理解为一个 HTTP服务器程序 主要要干两件事，一是要 接收来自客户端的请求 ， 以及根据这个请求做出相应的响应 。

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

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

静态服务器与动态服务器

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

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

Web框架

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

架构模式

MVC模式

MVC是 Model 、 View 、 Controller 的缩写。分别代表模型、视图、控制。

模型层：这一层表示核心的数据以及对数据的处理方法，处在最底层。
视图层：这一层是需要展示给用户看的内容。
控制层：这一层 处在模型与视图的中间 ，连接模型与视图。

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

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

Django的MTV模式

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

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

术与道

道，这个词可以说非常大。目前我认为 不论是什么架构模式、编程语言 ，都只是术，也就是只是工具，工具是 为了方便我们做事的 ，不能因为我们喜欢螺丝刀，就连敲钉子也要用螺丝刀。

前端与后端

HTML CSS JavaScript

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

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

HTML(HyperText Markup Language) ：超文本标记语言。注意标记这两个字，例如一个 h1 的标签，浏览器就知道，这里是一个一号大小的标题。
CSS(Cascading Style Sheets) ：层叠样式表。仅仅一个 h1 在浏览器中看上去可能不好看，通过CSS则可以决定这个 h1 的样式，例如变成红色文字。
JavaScript ：这是一个脚本语言，它使得网页具有交互能力，例如将鼠标移动到 h1 标题上会弹出一个下拉选择框。这也是之前为什么说只使用静态服务器的网站不代表网页是静态不能动的。

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

前后端分离与不分离

前后端分离这个问题在 C/S 中应该并不存在，毕竟人家本来就是分开的两套程序。 B/S 架构中，其实是前端与后端都在服务器上，由浏览器来呈现用户界面。

那么摆在最前面的问题是，前端与后端的分界线在哪里呢?

如果你认为只有用户能看到的部分才是前端，那么在 Django 中前端程序员好像只要负责模板层的代码，后端程序员要做更多的事，并且前端写代码的时候还要让后端来决定 插入模板代码 ，例如上一篇文章中我们在模板层写的类似 Python 的 {% for xx in xxx %} ，两方有点纠缠不清的感觉。

我想你可能已经意识到我要说什么了，前后端分离or不分离，也是术，是工具，我们要根据适不适合来选择工具。例如你需要一个 多平台应用 ，既有浏览器端，还要对应app， 那么前后端分离应该是你的选择 ，又比如你有一个 庞大的开发团队，需要前后端同时独立开发 ，那么 解耦合 的前后端分离模式也应该是你的选择。

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-article ， create-article ， update-article ， delete-article ，要 实现获取、创建、修改、删除操作 ，只需要客户端发送 对应的HTTP请求 就行（分别为 GET , POST , PUT , DELETE ）。统一资源标识符只应表示资源本身。