Django模型字段验证与DRF序列化器字段验证相关疑问

Great question—this is a super common point of confusion when working with Django and DRF, since both layers offer validation tools but serve distinct purposes. Let’s unpack your questions one by one:

1. What’s the Responsibility Split Between Model-Level and DRF Serializer Validation? #

Think of it like this:

• Django Model Validation: Acts as the last line of defense for data integrity. Its job is to ensure that no matter how data enters the database (whether via DRF API, Django Admin, shell commands, or backend scripts), it adheres to the core rules that keep your database consistent and valid. This is non-negotiable for data reliability.
• DRF Serializer Validation: Acts as the first line of defense for API interactions. Its job is to handle data coming from external clients (frontends, mobile apps, etc.), validate it against API-specific business logic, and return clear, user-friendly error messages. It’s focused on the API user experience and rules that only apply to API requests.

2. Where Should Different Types of Validation Be Deployed? #

Let’s map common validation scenarios to the right layer:

• Basic Data Integrity Rules (field types, non-null constraints, unique values, foreign key relationships):
  • Must go in the Model layer. Use built-in field parameters like null=False, unique=True, or ForeignKey(on_delete=models.CASCADE). For cross-field integrity (e.g., end time > start time), use the Model’s clean() method. This ensures every data entry path follows these rules.
• Core Business Rules (rules that apply to all data sources, e.g., "a user’s age must be 18+"):
  • Put in the Model layer’s clean() or clean_fields() method. This way, even if someone creates an object via the shell, the rule is enforced.
• API-Specific Validation (rules that only apply to API requests, e.g., password confirmation fields, input formatting for client consumption):
  • Put in the DRF Serializer. For example, a password_confirm field that doesn’t get saved to the database but needs to match the password field—this doesn’t belong in the Model. Use serializer methods like validate_<field_name>() or the top-level validate() method.
• Input Format/Transformation (e.g., converting a string to a DateTime, normalizing email addresses):
  • DRF Serializer is ideal. It’s designed to handle input/output transformation, and you can return precise error messages if the format is wrong (which is better for API clients than letting the Model throw a generic database error).

3. How Does DRF Serializer Validation Restrict Manual Database Entries? #

Short answer: It doesn’t—by design. DRF’s validation only runs when data passes through a serializer (i.e., API requests). If someone creates/updates objects directly via the Django shell, Admin, or a backend script, they’re bypassing the serializer entirely.

But here’s how you can enforce rules even for manual entries:

• Move critical rules to the Model layer: Any validation that must be enforced no matter what should live in the Model’s clean() method, and ensure full_clean() is called before saving. By default, Django’s Model.objects.create() doesn’t run full_clean(), so you can override the Model’s save() method to enforce this:

  from django.db import models
  from django.core.exceptions import ValidationError
  
  class Event(models.Model):
      start_time = models.DateTimeField()
      end_time = models.DateTimeField()
  
      def clean(self):
          super().clean()
          if self.end_time <= self.start_time:
              raise ValidationError("End time must be after start time")
  
      def save(self, *args, **kwargs):
          # Force validation before saving, even for manual entries
          self.full_clean()
          super().save(*args, **kwargs)
  

• Restrict access to manual entry points: If you want to prevent manual entries entirely, you can limit permissions for the Django Admin (e.g., only allow superusers to edit certain models) or restrict database user permissions so backend scripts can’t write directly. But this is more of an access control measure, not validation.

Quick Recap #

• Model validation = universal data integrity for all entry paths
• Serializer validation = API-specific rules and user-friendly error handling
• To restrict manual entries, embed non-negotiable rules in the Model layer and enforce full_clean() on save.

内容的提问来源于stack exchange，提问作者RaiBnod