Django（DRF）中的业务逻辑放在哪里？

Question

尽管这是一个非常受欢迎的问题并且已经有很多答案，但我不太明白。我知道在视图中放入大量逻辑并不是一个好主意，因此在我的项目中我创建了诸如

utils

、

logic

、

helpers

之类的文件。但问题是我不知道我应该在哪里调用那些“逻辑”函数？

我应该将它们作为模型实例的属性或方法，还是应该在视图中调用它并传递模型实例作为参数？例如，在我当前的宠物项目中，我有

Question

和

Answer

模型。

Question

有

is_solved

布尔 (

default=False

) 字段，表示问题是否已解决，

Answer

也有

is_solving

布尔字段 (

default=False

)，如果为 True，则表示答案帮助解决了一个问题。我在

logic

文件中有一个函数可以处理它。这是代码：

def vote_answer_solving(answer: Answer, related_question: Question):

    if answer.is_solving:
        answer.is_solving = False
        related_question.is_solved = False
    else:
        if related_question.question_answers.filter(is_solving=True).exists():
            is_solving_answer = related_question.question_answers.get(is_solving=True)
            is_solving_answer.is_solving = False
            is_solving_answer.save()
        answer.is_solving = True
        related_question.is_solved = True

    related_question.save()
    answer.save()

我在视图中调用它，用户请求端点，逻辑由函数处理。我真的不知道，也许我应该将逻辑放在模型

save

方法中，所以当它得到

is_solving=True

的答案时，相关问题状态

is_solved=False

更改为

True

。

这只是我对如何使代码更清晰的普遍误解的一个例子，特别是当我应该将逻辑放置在与视图类似的情况下（调用其中的分离函数）或在模型管理器或

的级别上处理它时save

方法。

Answer 1

可以在三个地方放置这样的逻辑，但视图函数只是其中之一。

1. 保存方法。 要考虑的第一个选项是覆盖模型的

   save

   方法。
2. 清洁方法。 您还可以重写模型的

   clean

   方法。尽管这是为了处理自定义验证而设计的，但它可以用于在调用保存方法之前访问输入的数据。
3. 预存信号。 最后一个选项是将模型连接到信号。 save 方法会触发

   pre_save

   信号，您可以使用该信号在保存模型数据之前对其进行操作。但是，由于信号可能会使您的代码难以维护和/或调试，因此 Django 建议谨慎使用它们。

值得注意的是，某些 ORM 操作（如

bulk_create

）不会调用

save

方法，选项 1 和 3 在这种情况下不起作用。