前端 后端 数据库
软件开发架构
cs架构
bs架构
# 本质bs也是cs
纯手撸web框架
HTTP
"""
HTTP协议 数据传输是明文的
HTTPS协议 数据传输是密文的
websocket协议
四大特性
1. 基于请求响应
2. 基于TCP/IP,作用于应用层之上
3. 无状态
4. 短/无链接
数据格式
请求首行
请求头
请求体
响应状态码
1XX
2XX 200
3XX 301 302
4XX 403 404
5XX 500
"""
如何做到后缀的不同返回不同的内容
拿到用户输入的后缀 做判断
不足之处
1. 代码重复 (服务端代码所有人都要重复写)
2. 手动处理http格式的数据 只能拿到url后缀 其他数据获取繁琐(数据格式一样 处理代码其实大致一样 重复写)
3. 并发的问题
借助于wsgiref模块
url.py 路由与视图函数对应关系
views.py 视图函数(后端业务逻辑)
templates文件夹 专门用来存储html文件
按照功能的不同拆分之后 后续添加功能只需要在urls.py中书写对应关系然后去views.py中书写业务逻辑即可
动静态网页
静态网页
页面上的数据是直接写死的 万年不变
动态网页
数据是实时获取的
eg:
1. 后端获取当前时间展示到HTML页面上
2. 数据是从数据库中获取的展示到HTML页面上
动态网页制作
import datetime def get_time(env): current_time = datetime.datetime.now().strftime('%Y-%m-%d %X') # 如何将后端获取到的数据传递给html文件 with open('templates/03 mytime.html','r',encoding='utf-8') as f: data = f.read() print('data:',data) # data就是一堆字符串 # data = data.replace('dadssadssad',current_time) # 在后端将html页面处理好之后再返回给诶前端 return data
将一个字典传递给html文件 并且可以在文件上方便快捷的操作字典数据
from jinja2 import Template def get_dict(env): user_dict = {'username':'jeffrey','age':20,'hobby':'read'} with open('templates/04 get_dict.html','r',encoding='utf-8') as f: data = f.read() tmp = Template(data) print('tmp',tmp) res = tmp.render(user= user_dict) print('res:',res) # 给 get_dict.html传递了一个值 页面上通过变量名user就能够拿到user_dict return res
后端获取数据库中数据 展示到前端页面
模板语法之jinja2模块
pip3 install jinja2
# 模板语法(非常贴近python语法) # 模板语法是在后端起作用的 {{user}} {{ user.get('username')}} {{ user.age}} {{user['hobby']}} {% for user_dict in user_list%} <tr> <td>{{ user_dict.id}}</td> <td>{{ user_dict.username}}</td> <td>{{ user_dict.password}}</td> <td>{{ user_dict.hobby}}</td> </tr> {% endfor %}
python三大主流web框架
django
特点:大而全 自带的功能特别多 类似于航空母舰
不足之处:
有时候过于笨重
flask
特点:小而精 自带的功能特别少 类似于游骑兵
第三方的模块特别多 如果将flask第三方的模块加起来 完全可以盖过django
并且也越来越像django
不足之处:
比较依赖于第三方的开发者
tornado
特点:异步非阻塞 支持高并发
牛逼到甚至可以开发游戏服务器
不足之处:
暂时你不会
A:socket部分
B: 路由与视图函数对应关系(路由匹配)
C: 模板语法
django
A 用的是别人的: wsgiref模块
B 用的是自己的
C 用的也是自己的 (没有jinja2好用 但是也很方便)
flask
A 用的是别人的: werkzeug (内部还是wsgiref模块)
B 自己写的
C 用的别人的 (jinja2) FastAPI
tornado
A,B,C 都是自己写的