我应该将我的 Django 和 DRF 项目拆分为单独的项目吗？答案

【问题标题】：Should I split my Django and DRF project into separate projects?我应该将我的 Django 和 DRF 项目拆分为单独的项目吗？
【发布时间】：2020-10-24 08:33:51
【问题描述】：

我目前正处于一个由标准组成的应用程序的规划阶段

主管的 Django 部分可以对员工用户执行所有 CRUD 操作，主要是添加、删除和查看统计信息 - 在浏览器中查看（没有前端框架，仅使用 Django 服务器端呈现），每次登录时两步电子邮件身份验证，基于会话的身份验证
员工的 DRF 部分 - API 连接到移动应用程序，基于设备 ID 的身份验证。（没有用户名或密码）
DRF 部分供客户在员工做错事时联系主管 - 使用邮件传递的密码进行基于令牌或 JWT 的身份验证。

我不习惯将 Django 项目拆分为多个子项目（或为不同的项目使用相同的数据库），但感觉项目的每个部分都应该是一个独立的应用程序，因为不同的身份验证类型和同时使用的事实带有标准 Django 的 DRF

任何有类似问题或有经验的人都可以告诉我在这个项目中考虑到不同的身份验证和整体不同的用户类型我应该怎么做？单独或多个项目的利弊是什么？
提前致谢！

【问题讨论】：

标签： django django-rest-framework entity-relationship django-authentication project-planning

【解决方案1】：

您是在征求意见，所以如果问题被关闭，请不要感到惊讶，但我会用事实回答：

使用同一数据库对不同项目进行拆分存在以下问题：共享迁移。它们都使用内置用户，因此需要启用一些具有迁移功能的标准应用程序，它们不会在第二个和第三个项目上运行。

您将需要一个自定义用户模型来支持设备 ID 身份验证方法：您需要在身份验证时可用的标准用户模型中没有的信息 - 这是创建自定义用户模型的第 1 个原因。与迁移相关联，也是代码方面的同步地狱。

Django 的 Authentication Backends 系统允许不同的身份验证方法同时存在，因此无需拆分任何东西。如果您担心安全性，您始终可以使用不同的主机名和站点框架来添加额外的保护层，但它们仍会使用相同的代码。

DRF 最初是对 Django 的基于视图的方法的补充，而不是作为 API 提供项目代码的一部分的替代品。虽然目前的使用更多的是“DRF 或模板”，但这是由于人们越来越多地变得二进制（“this”或“that”）并希望加入酷俱乐部，但与技术原因无关。在解决不同的问题时，它们可以并且总是能够共存。事实上，DRF 的通用视图利用了 Django 的 CBV，而内置的可浏览 API 则利用了模板。此外，admin 是基于模板/视图的，可以方便地开发应用程序或使用内置的 admin 管理数据。

【讨论】：

感谢您的详细回答，这有点像我所希望的，因为我不习惯使用共享数据库。您是否有任何可靠的学习资源可用于身份验证后端的专业定制？我只使用单个 AB 来允许邮件或用户名登录，所以我的知识很窄。（我的意思是除了我在 github 上阅读的大部分源代码的 Django 文档）
我建议研究一下 django-allauth，它有一个非常复杂的身份验证机制，它使用与 Django 共存的单一身份验证后端。 this excellent tutorial 中使用的 social-auth-app-django 也是如此。
我们如何才能同时使用服务器端渲染模板和标准会话身份验证系统，以及 API 端点和 JWT 身份验证？这如何与标准权限系统一起使用？我知道 DRF 在几种方法中寻找第一个成功的身份验证方法，但是在同一 URL 上提供 HTML 模板或 JSONResponse 是否相同？
@Hills DRF 没有单独的身份验证机制，它只是使用 Django 的，所以它是同一个系统。这就是为什么有像 dj-rest-auth 这样的包可以包装 django-allauth 的原因。它们可以共存的最简单示例是为前端设置djoser，登录（将使用 JWT 和您的 SPA），然后登录到您的管理员（将使用会话身份验证和服务器端呈现的页面）。