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

时间:2020-10-24 08:33:51

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

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

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

我不习惯将Django项目拆分为多个子项目(或将相同的数据库用于不同的项目),但是由于身份验证类型不同并且同时使用,我觉得项目的每个部分都应该是一个独立的应用程序具有标准Django的DRF

有类似问题或有一定经验的人可以建议我考虑该项目中的不同身份验证和总体不同的用户类型吗?进行单独或多个项目的利弊是什么?
预先感谢!

1 个答案:

答案 0 :(得分:1)

您要征求意见,因此,如果问题解决,请不要感到惊讶,但我会用事实回答:

使用同一数据库划分不同项目存在以下问题:共享迁移。他们都使用内置用户,因此需要启用一些具有迁移功能的标准应用程序,并且它们不能在第二和第三项目上运行。

您将需要自定义用户模型来支持设备ID身份验证方法:您需要标准用户模型上未包含的信息,以便在身份验证时可用-创建自定义用户模型的第一原因。与迁移相关,并与代码同步。

Django的身份验证后端系统允许同时存在不同的身份验证方法,因此无需拆分任何内容。如果您担心安全性,可以始终使用不同的主机名和Sites框架来添加额外的保护层,但是它们仍将使用相同的代码。

DRF最初是对Django基于视图的方法的补充,而不是代替使项目代码的一部分作为API可用。尽管当前使用的更多是“ DRF或模板”,这是由于人们越来越成为二进制文件(“ this”或“ that”)并且希望加入酷炫的俱乐部,但与技术原因无关。当他们解决不同的问题时,他们可以并始终能够共存。实际上,DRF的通用视图使用Django的CBV,而内置的可浏览API则使用模板。另外,管理员基于模板/视图,使用内置管理员可以方便地开发应用程序或管理数据。

相关问题