为何使用Django Model Manager？创建model.Manager子类是否必要？

Hey there! Let's start with the straight answer first: Using a custom Model Manager is NOT required at all. Django automatically gives every model a default objects manager out of the box, and you can use it for all standard CRUD and query operations (like Model.objects.all(), filter(), get()) forever if your project doesn't need anything fancy. Many simple projects run perfectly fine with just the default manager.

That said, there are some really good reasons to create a custom Manager subclass and assign it to your model—here are the most common ones:

1. Wrap Repeating Query Logic (The #1 Use Case) #

If you find yourself writing the same filter/query over and over across your codebase, a custom manager lets you encapsulate that logic in one place.

For example, say you have an Article model and you constantly need to fetch "published, active articles". Instead of writing Article.objects.filter(published=True, status="active") every time, you can do this:

from django.db import models

class ActiveArticleManager(models.Manager):
    def get_active_articles(self):
        return self.filter(published=True, status="active")

class Article(models.Model):
    title = models.CharField(max_length=200)
    published = models.BooleanField(default=False)
    status = models.CharField(max_length=20)
    
    # Replace the default manager with our custom one
    objects = ActiveArticleManager()

Now you can just call Article.objects.get_active_articles() anywhere. If you ever need to adjust the query (like adding a date_published__gte filter), you only have to change it in the manager—no hunting down every instance of that query in your code.

2. Override the Default Queryset #

The default objects.all() returns every instance of your model, but sometimes you want the "default" view of your data to exclude certain records (like soft-deleted items).

Take a User model with an is_deleted flag:

class ActiveUserManager(models.Manager):
    def get_queryset(self):
        # Return only non-deleted users by default
        return super().get_queryset().filter(is_deleted=False)

class User(models.Model):
    name = models.CharField(max_length=100)
    is_deleted = models.BooleanField(default=False)
    
    # Default manager shows only active users
    objects = ActiveUserManager()
    # Keep a separate manager to access ALL users (including deleted)
    all_users = models.Manager()

Now User.objects.all() gives you only active users, while User.all_users.all() lets you access the full dataset when needed. Super handy for keeping your day-to-day queries clean.

3. Add Custom Creation Logic #

Managers aren't just for queries—you can use them to wrap complex instance creation logic too. For example, auto-generating unique IDs, setting default values, or running post-creation actions (like sending notifications).

Here's an example for an Order model:

from django.db import models
import datetime

class OrderManager(models.Manager):
    def create_order(self, customer, total_amount):
        # Auto-generate a unique order number
        order_number = f"ORD-{datetime.datetime.now().strftime('%Y%m%d%H%M%S')}"
        # Create the order with pre-filled values
        order = self.create(
            customer=customer,
            total_amount=total_amount,
            order_number=order_number
        )
        # You could add extra steps here—like sending a confirmation email
        return order

class Order(models.Model):
    customer = models.ForeignKey("Customer", on_delete=models.CASCADE)
    total_amount = models.DecimalField(max_digits=10, decimal_places=2)
    order_number = models.CharField(max_length=20, unique=True)
    
    objects = OrderManager()

Now creating an order is as simple as Order.objects.create_order(customer_obj, 99.99)—no need to handle the order number generation every time.

4. Use Multiple Managers for Different Data Views #

You can assign multiple managers to a single model, each giving you a different "perspective" on your data. For a Product model, you might have one manager for in-stock items, another for low-stock items, and a third for all products:

class InStockProductManager(models.Manager):
    def get_queryset(self):
        return super().get_queryset().filter(stock__gt=0)

class LowStockProductManager(models.Manager):
    def get_queryset(self):
        return super().get_queryson().filter(stock__lte=5)

class Product(models.Model):
    name = models.CharField(max_length=100)
    stock = models.IntegerField(default=0)
    
    objects = models.Manager() # Default full dataset
    in_stock = InStockProductManager()
    low_stock = LowStockProductManager()

Now you can call Product.in_stock.all() or Product.low_stock.all() to get exactly the subset of data you need, with zero extra filtering in your views or business logic.

To Recap: Is a Custom Manager Mandatory? #

Nope! The default manager works great for basic use cases. Custom managers are a tool to make your code cleaner, more maintainable, and more readable by encapsulating repetitive logic. Use them when you start noticing patterns in your queries or creation workflows—it's totally optional, but can save you a lot of headache in the long run.

内容的提问来源于stack exchange，提问作者Md. Rabiul Islam