我有一个有趣的设计决定要在我计划最终发布的 Python Django 模型的上下文中做出。
这些类对 ApprovalRequest 进行建模,它表示用户提出的问题/请求,可以由另一个用户组投票,也可以上诉,然后可以由“更高级别”组再次投票,等等。
我有什么相当于以下模型树:
- ApprovalRequest(单个请求)
- 用户请求操作
- 行动类型* / 附加数据
- ApprovalStage(可能是多个投票阶段,按时间顺序排列)
- 相关的批准请求
- 投票类型(简单多数,需要一票等)
- 可以投票的用户*
- ApprovalVote(单票,由单个选民投票)
- 相关审批阶段
我的第一个问题与“动作类型”有关。因为我的意图是让它成为一个任何人都可以使用的可重用模块,所以我希望它在事件发生时发出信号。但是,此模型适用于许多事情 - 审核、用户提升、用户禁令上诉决定等。因此,需要某种“类型”参数。在 OOP 设计中解决此问题的经典方法是允许创建子类并具有自定义操作,这很好,但 Django(特别是)没有简单的方法从数据库中获取“正确”子类。例如,使用内置模型继承,将有一个主 ApprovalRequest db 表和 N 个附加 db 表,用于每个孩子的数据。
我最初的想法是创建一个子类“registry”,它会为我的类型字段分配一个唯一的 id,这样当我需要采取特定类型的操作时,我可以可靠地向下转换为注册类型。这将迫使子类为其子类选择一个(项目范围的)id,并且通常看起来不优雅。
我的第二个问题与“可以投票的用户”有关。我希望这些 ApprovalRequest 对象中的大多数实际上是由代码创建的,而不是通过例如 Django 管理员。假设发生以下动作:
- 用户请求促销(或其他操作)
- 创建 ApprovalRequest 对象,指定匹配某个代码相关组(即复杂查询集)的所有用户都可以投票
- 时间过去了,没有对 ApprovalRequest 采取任何行动
- 十个新用户现在满足复杂查询集的条件(也就是说,如果现在创建 ApprovalRequest,这些用户也将成为投票组的一部分)
- 我希望这些新用户能够投票
问题或多或少是,我如何以安全的方式存储这个复杂的查询集?我可以根据类型将这项工作委托给子类,但这似乎不优雅。我可以尝试以某种方式将查询集存储在数据库中,但这似乎有点 hacky。选择的标准路线是什么?
感谢您对这些问题的任何建议。