如何解决Django Rest Framework为什么不鼓励模型级别验证？
模型的“ full_clean”存在两个主要问题。第一个是技术性的。有几种情况根本不调用full_clean。例如，执行时将绕过它queryset.update()。
第二个问题是，如果你具有复杂的业务逻辑（通常这就是为什么要使用full_clean的原因），那么很有可能应该在业务逻辑中进行验证，而不要深入模型进行验证。每一层都应负责其自身的一致性，而存储层（即模型）不应在意业务层。
我能想到的另一件事是，一旦你拥有在序列化程序进行验证之后出现的模型，就会调用full_clean。此时，事情开始变得混乱，因为你需要在两步验证之间创建一个对象。
如果使用nested serializer，则可能会停留在这里，因为在保存主模型之前将无法创建嵌套模型，这将使完整的调用更为混乱-有些对象将被创建，而另一些则不会。很难确定何时以及使用他们的full_clean验证哪个对象，并且你可以确保用户在覆盖更新/清理并找出未调用full_clean时会收到很多抱怨。每个模型。这开始变得头疼不已，我们希望让事情更简单明了。
解决方法
Model.clean验证模型序列化器时，Django Rest Framework序列化器不会调用。给出的解释是，这导致了Django Rest Framework 3.0发行说明中的 “更清晰的关注点分离” ：
ModelSerializer验证和ModelForm之间的差异。
此更改还意味着我们不再.full_clean()在模型实例上使用该方法，而是在序列化程序上显式执行所有验证。这提供了更清晰的分隔，并确保在ModelSerializer类上没有自动验证行为，而该行为也不能轻易地在常规Serializer类上复制。