Django 视图 – FBV 与 CBV（长文讲解）

Django 视图 – FBV 与 CBV：两种编程范式的选择与实践

在 Django 项目开发中，视图（View）是连接 URL 与业务逻辑的核心枢纽。它负责接收用户的请求，处理数据，然后返回响应。Django 提供了两种主要的视图编写方式：函数视图（Function-Based Views，简称 FBV）和类视图（Class-Based Views，简称 CBV）。它们各有优势，理解它们的区别与适用场景，是提升开发效率与代码可维护性的关键一步。

想象一下，你正在设计一个餐厅的点餐系统。函数视图就像是一个单点的收银员，他负责处理每一笔订单，从接收点单、核对菜品、计算金额，到打印小票，整个流程由一个人完成。而类视图则像是一个完整的点餐服务台，它把“接收点单”、“验证库存”、“生成订单”等职责拆分到不同的方法中，由一个团队协作完成。这种设计上的差异，决定了它们在不同场景下的表现。

函数视图（FBV）：简洁直接，适合简单逻辑

函数视图是 Django 最原始、最直观的视图形式。它以 Python 函数的形式定义，接收一个 HttpRequest 对象作为参数，返回一个 HttpResponse 对象。

from django.http import HttpResponse
from django.shortcuts import render
from .models import Book

def book_list(request):
    # 1. 从数据库中查询所有书籍数据
    books = Book.objects.all()
    
    # 2. 将数据传入模板，渲染页面
    return render(request, 'books/book_list.html', {
        'books': books  # 传递书籍数据给模板
    })

这个函数的作用是：当用户访问 /books/ 路由时，Django 会调用 book_list 函数。函数从数据库获取所有书籍，然后使用 render 函数将数据传递给 HTML 模板，最终返回渲染后的页面。

函数视图的优势在于：

• 代码结构简单，初学者容易理解
• 逻辑清晰，适合处理单一、明确的业务流程
• 调试方便，执行路径一目了然

但它的局限也很明显：当业务逻辑变得复杂时，函数会变得臃肿，难以维护。比如，你可能需要在多个视图中重复写相同的权限检查、日志记录、数据缓存等代码，这违背了“不要重复自己”的开发原则。

类视图（CBV）：结构化设计，适合复杂场景

类视图通过 Python 的类来组织视图逻辑。它将视图拆分为多个方法，每个方法负责特定的职责，如 get() 处理 GET 请求，post() 处理 POST 请求。

from django.views.generic import ListView, CreateView
from django.urls import reverse_lazy
from .models import Book
from .forms import BookForm

class BookListView(ListView):
    model = Book  # 指定模型，自动查询所有数据
    template_name = 'books/book_list.html'  # 指定模板文件
    context_object_name = 'books'  # 模板中使用的变量名

class BookCreateView(CreateView):
    model = Book  # 指定模型
    form_class = BookForm  # 指定表单类
    template_name = 'books/book_form.html'  # 模板
    success_url = reverse_lazy('book_list')  # 成功后跳转的 URL

    # 可选：重写方法，添加额外逻辑
    def form_valid(self, form):
        # 在表单验证通过后调用
        form.instance.author = self.request.user  # 自动设置作者为当前用户
        return super().form_valid(form)

在这里，BookListView 继承自 ListView，它已经内置了查询数据、分页、模板渲染等逻辑。我们只需要配置 model 和 template_name，就可以快速实现一个功能完整的列表页。

类视图的优势在于：

• 代码复用性强，多个视图可以共享相同的逻辑
• 支持方法级别的扩展，便于定制行为
• 适合处理复杂的请求流程，如表单处理、权限控制、缓存等

但它的学习成本较高，初学者可能难以理解 self.get_queryset()、self.get_context_data() 等方法的作用。

FBV 与 CBV 的核心差异对比

从这张表可以看出，选择哪种方式，关键在于项目规模和复杂度。如果你正在开发一个个人博客，只有几个页面，FBV 足够高效。但如果你在构建一个电商平台，涉及用户管理、订单流程、支付回调等复杂逻辑，CBV 的结构化优势将大大提升代码的可维护性。

实际项目中的选择建议

在实际开发中，我建议采用“混合策略”：简单功能用 FBV，复杂功能用 CBV。

比如，在一个博客系统中：

• 显示文章列表 → 用 ListView（CBV）
• 显示单篇文章 → 用 DetailView（CBV）
• 发布新文章 → 用 CreateView（CBV）
• 但像“首页统计”这样的小功能 → 可以用函数视图快速实现

from django.shortcuts import render
from django.views.generic import ListView
from .models import Article

def home_stats(request):
    total_articles = Article.objects.count()
    return render(request, 'home.html', {
        'total_articles': total_articles
    })

class ArticleListView(ListView):
    model = Article
    template_name = 'articles/list.html'
    paginate_by = 10  # 每页显示 10 条

这种做法既能保持代码的简洁，又能利用 CBV 的强大能力。记住：不要为了用 CBV 而用 CBV，也不要因为怕复杂而拒绝它。合理选择，才是高手之道。

高级技巧：自定义类视图与方法重写

类视图最强大的地方在于可以重写其方法来定制行为。比如，你可能希望所有视图都自动记录访问日志。

from django.views.generic import View
from django.http import HttpResponse
import logging

class BaseView(View):
    def dispatch(self, request, *args, **kwargs):
        # 在请求处理前执行
        logging.info(f"用户 {request.user} 访问了 {request.path}")
        return super().dispatch(request, *args, **kwargs)

    def get_context_data(self, **kwargs):
        # 为模板提供额外上下文
        context = super().get_context_data(**kwargs)
        context['site_name'] = '我的博客'
        return context

class MyView(BaseView):
    def get(self, request):
        return HttpResponse("Hello, world!")

在这里，dispatch() 方法在每个请求进入时自动调用，实现了统一的日志记录。get_context_data() 可以在模板中使用 site_name 变量。这种模式让你可以轻松构建“插件化”的视图系统。

总结：理解本质，灵活运用

Django 视图 – FBV 与 CBV 的选择，本质上是“简洁”与“结构化”的权衡。函数视图像一把瑞士军刀，小巧灵活；类视图则像一套精密工具箱，功能强大但需要学习成本。

作为开发者，我们不必非此即彼。在项目初期，用 FBV 快速验证功能；随着业务增长，逐步将复杂逻辑迁移到 CBV。这种渐进式演进，既能保证开发效率，又能提升代码质量。

记住：没有绝对“更好”的方式，只有“更合适”的选择。理解每种方式的本质，才能在面对不同需求时，做出明智的决策。