前言本文简单说一下在后续开发工作中可能会遇到的一些概念。更好的学习资源，尽量避免读者以后遇到这些概念时一头雾水。当然，我不是权威人士。这篇文章的内容是基于我目前的认知。难免会有谬误。如果需要深入理解，还是需要多查资料，在实践中消化。Word网络时代的程序在网络时代，如果不考虑游戏，人们日常生活中似乎很少有不需要网络的软件。相信大家至少都用Python写过一些简单的小脚本。这些程序只在我们自己的电脑上运行，不与其他人交流，甚至只是在运行前做一些简单的计算。当然，每个人都有社交需求，电脑也需要谈恋爱。想要深入了解，建议多搜索计算机网络相关内容。C/SClient-Server：客户端-服务器架构。这个相信大家都不陌生，比如常用的QQ和微信。要使用这类程序，我们需要在电脑或者手机上安装它们的客户端，这个客户端程序会和各自的服务器程序进行通信，如果我们想用QQ给朋友发消息，那么通常是发给腾讯的消息服务器通过我们的客户端，然后服务器发送给朋友的客户端。当然，这个过程并不像发送和接收那么简单。需要注意的是，这个客户端并不一定只有GUI，即有图形用户界面的程序就是客户端。许多客户您可能无法直接看到该程序。B/SBrowser-Server：浏览器-服务器架构。这个大家一定比较熟悉，平时浏览的各种网站都是这种模式。有些人认为网站不能被视为计算机程序。我不同意这一点。对比谈谈我对这两种模式的理解。不知道为什么有人认为C/S和B/S是两个不同的东西并列。我认为其实B/S是属于C/S的。试想一下，我们使用浏览器来浏览一个网站。其实这个浏览器不就是一个客户端程序吗？只是无数的网站服务器共享浏览器作为客户端。我觉得所谓B/S只是C/S的一种特殊，那么这样做有什么好处呢？想一想，你有没有需要经常更新手机上的软件，比如QQ，经常腾讯出新功能，那么用户需要更新客户端，通过浏览器访问的网站，只要浏览器支持它的前端功能，用户往往不需要做任何事情就可以体验到新的功能。随着互联网的发展，网速越来越快，延迟越来越低。甚至有人提出把所有的应用都放在云端，比如把手机变成一个大浏览器，手机只负责显示内容。需求也已经转移到对网络速度的需求上。当然，现在的网速还不够快。之前玩过云游戏，一般配置的电脑直接玩大型游戏就可以了，但是现在体验不是很好。微信的小程序功能也体现了这一理念。许多简单的应用程序不需要在我们的手机上安装单独的应用程序。WebServer通信协议通信协议是一个很重要的东西。它规定了计算机应该如何通信。如果没有达成一致，那就是鸡同鸭讲，互联网无从谈起。例如，在人与人之间的交流中，我们知道我们语言的语法规则和句子中单词的含义。这是说同一种语言的人都知道的规则。我们可以把大脑中的信息编码成声音信号发出去，听话的人也知道如何把这个声音信号解码成大脑可以理解的信息。而一只鹦鹉，虽然它也能接收到我们发出的声音信号，但是它不懂我们的语法规则，它永远只能学舌头，却无法与我们交流。在B/S架构的程序中，通信基本都是基于HTTP协议。建议重点理解TCP/IP和HTTP协议。在这里，服务器不仅仅是指一种计算机硬件。实际上，网络服务器是软件和硬件的结合体。没有软件，只有一台电脑什么都做不了，只有软件没有运行环境也是一样。请求与响应我理解一个HTTP服务器程序主要做两件事，一是接收客户端的请求，根据请求做出相应的响应。比如你访问网站a.com，服务器会根据你的GET请求返回一个响应，其中包含该网站首页的HTML文件，浏览器就会将这个页面呈现给你。另一个非常常见的响应是当您请求不存在的资源时，您将看到404页面。静态服务器和动态服务器静态服务器并不是说把响应的内容渲染成静态页面，而是服务器上的资源是原样交付给你的。动态服务器不同。动态服务器通常包含一个数据库，资源根据数据库的内容动态更新，然后通过静态服务器呈现给您。Web框架很容易理解。框架是一个为你省事的工具。从头开始开发一个系统是非常麻烦的。前人栽树，后人乘凉。使用Web框架可以帮助您快速开发并节省时间。Django是一个非常好的网络框架。架构模式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。艺与道，这个词可以说是很大了。目前我觉得不管是什么架构模型，什么编程语言，都只是一种技术，也就是一种工具。工具是为了方便我们的工作。我们甚至不能用螺丝刀敲钉子，因为我们喜欢螺丝刀。前端和后端HTMLCSSJavaScript这三样东西基本上是一个网站必不可少的。前面提到B/S只是C/S的一种特殊类型，那么浏览器客户端是根据什么让各种网页看起来不一样，功能不一样呢？HTML（HyperTextMarkupLanguage）：超文本标记语言。注意标记这两个词，比如一个h1标记，浏览器就会知道这是一个sizeone的标题。CSS（CascadingStyleSheets）：层叠样式表。就一个h1在浏览器中可能不太好看，但是这个h1的样式可以通过CSS来确定，比如变成红色文字。JavaScript：这是一种使网页具有交互性的脚本语言，例如将鼠标移到h1标题上会弹出一个下拉选择框。这就是为什么之前说只使用静态服务器的网站不代表网页是静态的不能移动的原因。推荐去MDN系统学习，但是由于一些历史原因，JavaScript学起来有点难受（说实话，刚开始接触这门语言的时候，我还以为是狗屎，跑路），请努力。前端分离和非分离前端分离的问题在C/S中应该是不存在的，毕竟它们本来就是两个独立的程序。B/S架构中，前端和后端都在服务器上，浏览器呈现用户界面。那么第一个问题就是，前端和后端的分界线在哪里？如果你认为只有用户能看到的部分是前端，那么在Django中，前端程序员似乎只负责模板层的代码，后端程序员要做的更多事情，而前端写代码的时候，后端必须决定插入模板代码。比如上一篇我们在模板层写了类似Python的{%forxxinxxx%}。双方感觉有些纠缠。我想你可能已经意识到我要说什么了。前后端分离与否，也是一门技术，也是一门工具。我们要根据适不适合来选择工具。例如，如果您需要一个同时具有浏览器和应用程序的多平台应用程序，那么分离前端和后端应该是您的选择。比如你有庞大的开发团队，需要同时独立开发前后端，那么解耦的前后端分离模式也应该是你的选择。RESTfulAPIREST(RepresentationalStateTransfer)：表现层状态转移。这个名字其实很直观。比如我们博客应用中一篇文章的实际资源可能是一串字符串，但是当呈现给表现层的时候，我们可以把它变成一个txt文件，HTML或者JSON。也就是说，服务器端的资源在客户端获取到之前会发生状态转换。因为HTTP协议是无状态协议，客户端使用不同的HTTP请求，使服务端将原来的资源转换成不同的状态并响应回来。RESTfulAPI的一个重要概念是URI（UniformResourceIdentifier）统一资源标识符，应该是名词而不是动词。比如博客中的一篇文章，访问它的URI可以是article，比如www.api.blog.com/article/，而不是get-article、create-article、update-article、delete-article，实现获取、创建、修改、删除操作，只需要客户端发送相应的HTTP请求（分别为GET、POST、PUT、DELETE）。统一资源标识符应该只代表资源本身。Django可以通过使用DjangoRESTframework库来实现这一点，后面会重点介绍。基于此也可以实现前后端分离开发，前后端约定接口，通过JSON交换数据。推荐文章总结个人博客其实不需要前后端分离的开发模式，甚至根本不需要写代码，直接有应用即可。在这里我还是想表达一下我的主要观点：学习的时候多造轮子，工程的时候多用轮子。也就是如何在学习的时候尽可能多的折腾、折腾，在实际的生产生活中尝试去应用成熟的、已有的应用。扫描二维码关注龚自政宅家日常，第一时间查看最新推送：
