Django走过的一些弯路-项目结构

我学习 Python 的路线可能和大部分人不一样，当时领导安排任务想做一个运维平台之类的平台，那个时候我还是只会写 shell 的小菜鸟。调查了一周，总结发现 Python 容易上手，Django 框架较为全面，于是直接看 Django 文档。所以一般是：构思想实现的功能 -> google 功能在 django 中如何实现 -> 自己尝试编写 -> 遇到问题继续 google，重复这个过程直到想实现的功能完成。这种学习方法能快速达到工作目标，是一种自上而下的学习方法，区别于自下而上的学习方式就是基础知识不够扎实，到现在基本都摸透了，总结一下走的弯路。

Demo 项目

项目结构#

首先的首先，我认为一个项目的结构是最重要的。就好比人类的骨骼，清晰明确的项目结构有利于模块分离，复用，且对于自己或者看你代码的人都是一种享受。

最早的时候，我的项目都是在根项目中，写的代码都是在根项目的 views.py 中，很快这个文件就超过 2k 行，每次打开需要等一会。就连 Pycharm 某些插件都罢工了 (大于 1000 行的文件出于运行效率问题会忽略)😹。

通过自己一段时间的摸索和查看开源项目等总结，以下结构对我来说比较适合。

• 项目结构

    ├── README.md                   # 说明文件
    ├── apps                        # 子项目目录
    │   ├── README.md                   - # 项目规范说明文件
    │   ├── app1                        - # 自定义模块一
    │   ├── app2                        - # 自定义模块二
    │   ├── ...                         - # 更多自定义模块，每个模块一个文件夹
    │   └── user                        - # 用户模块（单独抽离出）
    ├── main                        # 项目主目录
    │   ├── __init__.py
    │   ├── asgi.py
    │   ├── settings.py             # 主配置文件
    │   ├── urls.py                 # 请求URL主入口
    │   └── wsgi.py
    ├── db.sqlite3                  # 自带数据库（仅开发环境）
    ├── env                         # 不同环境的配置文件
    │   ├── README.md                   - # 环境配置说明
    │   ├── env.example                 - # 配置示例文件
    │   └── env                         - # 环境配置文件
    ├── logs                        # 日志
    │   ├── access.log                 - # 访问日志
    │   ├── error.log                  - # 错误日志
    │   └── uwsgi.log                  - # 运行日志
    ├── manage.py
    ├── reload                      # (uwsgi) 监听该文件变动重启服务
    ├── requirements.txt            # 项目依赖
    ├── static                      # 静态资源文件
    │   ├── css
    │   ├── image
    │   └── js
    └── uwsgi.ini                   # uwsgi配置文件Copy

  以下几个目录比较关键

  • apps 关于实现的所有业务逻辑，每个模块单独起一个 app 写，相关逻辑放到对应 app
  • main 根项目，框架启动入口。不实现任何业务逻辑。固定名称，就叫 main。
  • env 项目配置目录，包含一个项目配置实例。通常会以文件的方式通过容器挂载。

• app 结构（偷懒就截个图）

  

  • views.py,urls.py 不要写到单个文件中，否则一旦接口数量变多就比较难维护，拆开放置到不同文件中。（之前很长一段时间只能靠 Ctrl + F 搜索…）
  • filter方法 , serializer方法不要和 models 写到一起，放到单独的文件中。
  • 抽离出 App 可以复用的功能，封装成工具类。我是放到了 utils 中，网上也有说建立一个 common.py 的是一样的道理。

举例当我想找 [用户管理] -> [后台系统] 的 api 时，我可以很快速的定位到 apps -> user -> urls -> http -> system，再也不用去一个大的 views.py 中使用搜索啦

总结：相同功能的模块配置，功能，抽离出来放到单独的文件。

放一个总的图片

本作品采用《CC 协议》，转载必须注明作者和本文链接