结构十分重要,一家公司很可能有很多项目,人员也经常流动,有一套软件管理方法能极大增加效率
结构层级 | 层级名 | 作用 | 子层级名 | 作用 | 用到的语句 |
---|---|---|---|---|---|
终端显示层 | \ | \ | |||
开放接口层 | 对外API:安全控制、流量控制 | \ | \ | ||
处理层 | Web层 | 参数校验 | 请求处理层 | \ | |
处理层 | 定时任务层 | 直接调用业务逻辑层 | |||
业务逻辑层 | biz层 | 业务顺序 | Service层 | 普通业务逻辑 | |
业务逻辑层 | biz层 | 业务顺序 | biz层 | 复杂业务逻辑 | |
通用业务处理层 | Manager层 | 处理第三方API、缓存方案、与DAO层交互 | \ | \ | |
数据持久层 | DAO层 | 与数据库交互 | DTO层 | 字段对象 | |
数据持久层 | DAO层 | 与数据库交互 | DAO层 | SQL、CURD | try:except: |
外部API | 微信登陆、支付宝等等 | \ | \ |
—————————上面是新的———————————
命名
接口路由层
数据库表结构
数据库表操作
Redis表操作
util工具-列表工具
util工具-json工具
util工具-api工具
命名好就不用找来找去
如果要文件目录就算是目录
就要26字母命名,自己可以按照喜好设置命名前缀
A
B
C - config - 配置文件
D - 主要代码
E - 主要代码
F - 主要代码
G - 主要代码
H - 主要代码
I - 主要代码
J - 主要代码
K - 主要代码
L - 主要代码
M - mysql数据库
M - mongodb数据库
N
O
P
Q
R - redis数据库
S
T
U - 工具类 - util工具-列表工具
U - 工具类 - util工具-json工具
U - 工具类 - util工具-api工具
V
W
X
Y
Z
一般程序有5-10个分类:
一个分类10个接口左右:
一般程序有50-100个接口:
PC端 - 未登录状态
PC端 - 已登录状态
PC端 - 已登录状态 - 数据分析
移动端 - 未登录状态
移动端 - 已登录状态
移动端 - 已登录状态 - 数据分析
小程序端 - 未登录状态
小程序端 - 已登录状态
小程序端 - 已登录状态 - 数据分析
作用 | 文件夹名 | 文件名 |
---|---|---|
config项目配置 | config | mysql.py(一般只有一个就够了config.py) |
Mysql的表结构model | model | 表名.py |
Mysql的表操作modules | modules | 表名_M.py |
Redis的表操作 | Redis | redis_0.py |
util工具 | util | utils_list.py |
util工具 | util | utils_dict.py |
util工具 | util | utils_api.py |
util工具 | util | utils_login.py |
测试
根据英文排序命名
只要分配一下,就不会找来找去
过了很久时间,检查的时候也会很快找到,
分配得好分分钟看目录就知道整个逻辑
一个接口,一个py.文件
路由:
aaa, bbb = 参数验证()
表1.查()
apputil.表1查1()
表2.查()
apputil.表2查1()
表2.查()
apputil.表2查2()
数据库事务开始()
表1.改()
表2.改()
表2.改()
数据库事务结束()
def 参数验证():
aaa
bbb
return aaa, bbb
所有逻辑都应该在路由里可以看见,不用到处找
list、json操作不要在这里写会乱
一个表,一个py.文件,AAA.py
class AAA:
列1
列2
列3
class AAA_M:
def get():
data = 查()
return
def get_j():
data = 查()
return json.loads(data)
最好有顺序(查、增、改、删)
不要有其他列表操作
redis_0_M.py
class redis_0_M:
def get(key):
data = redis_0.get(key)
return data