前言#
最近做的这个项目大量使用了 python 及其相关的生态，因此自然而然选择了我的 DjangoStarter 作为后端框架
之前 v2 版本是用 RestFramework 做接口的，后面我试用了一次 django-ninja 之后就喜欢这种类似 FastApi 的写接口方式
正所谓天下苦 drf 久矣，在新的 v3 版本框架中，我决定直接把整个 RestFramework 替换成 ninja
目前大部分功能都完成了，代码在主项目的 v3-alpha 分支里，等开发完成我会合并到 master 里 （现在基本可用了）
另外还做了很多新功能和改进，接下来会介绍一下
关于 DjangoStarter#
这个开发脚手架，最开始还是叫 DjangoRails ，名字模仿的 Ruby on Rails
后面经过重构才改成 DjangoStarter
这个脚手架起源于2020年开始的项目，当时使用 Django + RestFramework 作为后端框架，为了满足安全部门的要求，又做了很多魔改，再加上其他一些配置啥的，慢慢的就积累出了 DjangoStarter ~
这里贴一下项目介绍吧~
DjangoStarter v3 是下一代 Django 项目快速开发模板，专为提升开发效率和性能而设计。
结合了 Django 的丰富功能和 Django-Ninja 的性能、灵活、简洁特性，v3 版本旨在为开发者提供一个更加强大、简洁和高速的开发体验。
通过这个全新的框架版本，开发者能够迅速搭建起符合现代 web 应用标准的项目基础架构。
核心特性#
- Django Ninja 集成：采用 Django Ninja 替代传统的 Django Rest Framework，为 API 开发带来了性能优化和更简洁的编码体验。利用 Python 类型提示，自动生成交互式 API 文档，不再需要 drf-yasg 那一堆繁琐的手动配置文档，同时提升了代码的可读性和维护性。
- 增强的安全性：内置了多项安全功能，包括但不限于 Admin 登录验证码、IP 限制等，确保应用的安全性。
- 代码自动生成：v3 版本进一步优化了代码生成器，丢掉了 DRF 这个包袱，只需要定义模型，就可以生成 schema 以及 RESTFul API，还能根据定义自动创建测试用例，大大提高开发效率。
- 随机种子数据生成：v3 版本内置 seed 模块，支持为已有模型自动填充假数据，方便开发测试。
- 模块化项目结构：推出了更加模块化的项目结构设计，方便开发者根据需要添加或移除功能模块，使项目维护更为简单。
- 现代化前端集成：提供了对现代化前端技术的集成，以及利用 NPM 和 gulp 管理前端资源，帮助开发者打造富交互式的用户界面。
- 容器化支持：内置 Dockerfile 和 docker-compose.yml 配置，简化了容器化部署的过程，支持一键部署到任何支持 Docker 的环境。
- 详尽的文档与社区生态：提供全面的文档和指南，覆盖从项目启动到部署的每一个步骤。同时，基于活跃的 Django 开源社区，开发者可以轻松获取支持和反馈。
关于v3版本#
OK，终于说回正题
这次重构v3版本最主要的原因是把 RestFramework 替换成 ninja
然后也做了一些新的功能
比如：
- 新的自动代码生成功能
- 完善了单元测试和集成测试，搭配代码生成，可以为每个应用自动生成 crud 的测试用例
- 随机种子数据，目前使用 faker 实现假数据，打算进一步实现类似 EFCore 的种子数据机制，使假数据更自然
- 新的登录接口
- 多种第三方登录接入（目前接了微信、小程序、企微）
- 使用 tailwindcss 替换 bootstrap 实现前端（只是一些简单的后台展示，还是以 API 为主）
- 拆分 settings 配置，像 AspNetCore 那样支持多个环境配置
- 更换了包管理器
目前大概就这些吧
后面有用到什么新的再一步步加入
代码生成#
一直没有好好介绍一下 DjangoStarter 框架的具体实现
代码生成这块其实也不复杂，包名是 django_starter.contrib.code_generator
主要就两个部分
- 分析器 -
src/django_starter/contrib/code_generator/analyzer.py - 生成器 -
src/django_starter/contrib/code_generator/generator.py
分析器使用 django.apps.apps 提供的 get_app_config 和 get_models 来扫描已注册的所有 App
然后搭配反射（或者在 Python 中应该叫自省 inspect）来获取各个字段的信息，把搜集到的信息保存到我定义的几个对象中
然后在生成器部分，根据特定的规则，使用 jinja2 模板进行渲染~
注意要把字段的 primary_key, is_relation 这些属性拿出来，后面有用。如果是关系字段（如外键）的话，还需要把 target_field 拿出来。
大概思路就是这样，其中有很多细节的地方，本文的篇幅受限，后续我写篇文章来介绍吧。
API#
使用 ninja 来写 API
不同于之前的 RestFramework ，ninja 用的是装饰器来定义路径，这个对于不喜欢 Django 配置式路由的人来说很友好
项目结构我也做了一些调整
以 demo 应用为例
每个 model 都在 apis 下单独创建一个 package，单独有 apis.py 和 schemas.py 代码，这样不会把所有代码逻辑混在一起
PS：后续如果我转向使用 FastApi，也可以用这个思路来组织项目
demo
├─ tests
│ ├─ __init__.py
│ ├─ test_music_album.py
│ ├─ test_music.py
│ ├─ test_movie.py
│ └─ test_actor.py
├─ migrations
│ ├─ __init__.py
│ └─ 0001_initial.py
├─ apis
│ ├─ music_album
│ │ ├─ __init__.py
│ │ ├─ schemas.py
│ │ └─ apis.py
│ ├─ music
│ │ ├─ __init__.py
│ │ ├─ schemas.py
│ │ └─ apis.py
│ ├─ movie
│ │ ├─ __init__.py
│ │ ├─ schemas.py
│ │ └─ apis.py
│ ├─ actor
│ │ ├─ __init__.py
│ │ ├─ schemas.py
│ │ └─ apis.py
│ └─ __init__.py
├─ __init__.py
├─ views.py
├─ models.py
├─ apps.py
└─ admin.py
坑点#
要说的话，ninja 这种比较新的库，还是有一点点坑的地方的
- 有些文档不够详细
- URL reverse 功能不够好用，只能在
NinjaAPI对象配置urls_namespace，下面的各级 router 都不能配置urls_namespace，我只能对下面的接口用url_name='demo/movie/list'这种形式的命名 - ModelSchema 对外键的支持有限，对于输入的 schema ，不能在 Meta.fields 里配置这个外键字段，需要自己单独写出来，这点对于自动生成代码来说有点麻烦，不过我已经解决了
种子数据/假数据#
这个可以叫 seed data ，也可以叫 mock data
在开发测试中很有用，不用手动去添加各种数据
包名是 django_starter.contrib.seed
一开始我是找到了一个叫 django-seed 的库，可以实现种子数据的生成
不过这个包已经年久失修，好几年没更新了
我试了一下，运行起来居然还依赖 PostgreSql 的库？！
就离谱，不应该和数据库无关的吗……
算了，我自己写得了，又不难
Python 生态就是好，Faker 库用来生成随机假数据很好用
主要代码在 src/django_starter/contrib/seed/seeder.py 文件里
就是根据不同的字段类型，使用不同的假数据方法
坑点：外键#
其中外键字段会比较坑，需要做一些特殊处理
related_model = field.related_model
# Ensure there is at least one instance of the related model
related_instance = related_model.objects.order_by('?').first()
if not related_instance:
related_instance = related_model.objects.create(**self.seed(related_model))
# Set the foreign key ID field
fake_data[field.attname] = related_instance.pk
settings 拆分#
早就对 Django 的配置 settings.py 不爽了
项目一大，这个文件就乱七八糟又臭又长
而且还不支持多环境切换，得自己写一堆逻辑去判断不同环境
之前版本中，我是把几个主要的配置拆分成不同文件，然后在 settings.py 里引用
现在我用上了 django-split-settings 这个包，瞬间舒服了
来看看现在的 config 目录
config
├─ settings
│ ├─ environments
│ │ ├─ __init__.py
│ │ ├─ testing.py
│ │ ├─ production.py
│ │ ├─ local.py.template
│ │ └─ development.py
│ ├─ components
│ │ ├─ __init__.py
│ │ ├─ simpleui.py
│ │ ├─ rq.py
│ │ ├─ ninja.py
│ │ ├─ logging.py
│ │ ├─ django_starter.py
│ │ ├─ database.py
│ │ ├─ csp.py
│ │ ├─ cors.py
│ │ ├─ common.py
│ │ ├─ captcha.py
│ │ └─ caches.py
│ └─ __init__.py
├─ __init__.py
├─ wsgi.py
├─ urls_root.py
├─ urls.py
├─ env_init.py
├─ asgi.py
└─ apis.py
可以看到现在 settings 变成了一个 package
各种配置拆分出来分散到 components 下面
然后不同的环境又放到 environments 下面，可以覆盖前面定义的配置
很好的解决了之前的几个痛点
更换包管理器#
原本就直接使用 pip ，搭配 requirements.txt 来管理依赖
这个方式的优缺点我就不多说了
这次换成 pdm ，总算有点现代包管理器的感觉了
PS：其实我之前还用过 poetry ，不过偶尔会遇到一些奇奇怪怪的问题，弃了~
小结#
大概就这些吧，后面有什么新的想法我再来更新
还有其中几个关键的更新我可能会单独写文章来详细介绍~