Django is one of the most widely used web frameworks in the Python ecosystem. It provides developers with a structured, secure, and efficient way to build web applications. At the heart of every Django application is the concept of a view. A view is responsible for receiving a web request, processing it, and returning a web response. In Django, views can generally be written in two main styles: function-based views and class-based views.

This article focuses on function-based views, often abbreviated as FBVs. Function-based views are the original and most straightforward way to write views in Django. They are simple Python functions that take a request object as an argument and return an HTTP response. Despite the popularity of class-based views, function-based views remain extremely useful, especially for beginners, small applications, custom logic, and cases where clarity is more important than abstraction.

What Is a Function-Based View?

A function-based view in Django is a Python function that handles an HTTP request. At minimum, it accepts one required parameter: request. This request object contains information about the incoming HTTP request, such as the method used, submitted form data, session data, user authentication details, cookies, headers, and more.

A very simple function-based view looks like this:

1
2
3
4

from django.http import HttpResponse

def index(request):
    return HttpResponse("Welcome to my Django website!")

In this example, the index function receives a request and returns an HttpResponse object containing plain text. When a user visits the URL connected to this view, Django executes the function and sends the response back to the browser.

Function-based views are easy to understand because they follow a direct request-response pattern. A request comes in, the function runs, and a response goes out. This simplicity is one of their greatest strengths.

Connecting a Function-Based View to a URL

Writing a view is only part of the process. Django also needs to know which URL should trigger that view. This is done using the URL configuration, usually inside a file named urls.py.

For example:

1
2
3
4
5
6

from django.urls import path
from . import views

urlpatterns = [
    path("", views.home, name="home"),
]

Here, the empty string "" represents the root URL of the application. When a user visits that URL, Django calls the home view. The name="index" part gives the route a reusable name, which is helpful when linking to it from templates or redirecting users.

This separation between URL routing and view logic is one of Django’s core design principles. URLs define where requests go, while views define what happens after a request arrives.

We have a full article covering URLs in Django right here: URLs in Django applications

Returning HTML with Templates

While returning plain text is useful for simple examples, most real Django applications return HTML pages. Instead of writing HTML directly inside the Python function, Django encourages developers to use templates.

A function-based view that renders a template might look like this:

1
2
3
4

from django.shortcuts import render

def home(request):
    return render(request, "home.html")

The render() shortcut combines a template with optional context data and returns an HttpResponse. The template file, such as index.html, usually lives inside a templates directory.

Context data can also be passed to the template:

1
2
3
4
5
6

def profile(request):
    context = {
        "username": "Alice",
        "role": "Developer"
    }
    return render(request, "profile.html", context)

Inside the template, the data can be displayed like this:

This makes function-based views useful for generating dynamic web pages. The view prepares the data, and the template controls how that data is displayed.

You can find an article covering Django's templatetags here:Basic Django Template Tags: A Complete Guide

Handling Different HTTP Methods

Web applications often need to respond differently depending on the HTTP method used. A GET request usually retrieves a page, while a POST request often triggers state-changing events.

Function-based views make this logic explicit:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

from django.shortcuts import render, redirect

def contact(request):
    if request.method == "POST":
        name = request.POST.get("name")
        message = request.POST.get("message")

        # Process the submitted data here

        return redirect("thank_you")

    return render(request, "contact.html")

In this example, the view checks whether the request method is POST. If it is, the view reads data from request.POST, processes it, and redirects the user. If the request is not POST, the view simply displays the contact form.

This explicit control is one reason many developers prefer function-based views for forms and custom workflows. The logic is easy to trace because everything is inside a single function.

Using Django Forms in Function-Based Views

Django provides a powerful form system that handles validation, error messages, and cleaned data. Function-based views work very well with Django forms.

For example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

from django.shortcuts import render, redirect
from .forms import ContactForm

def contact(request):
    if request.method == "POST":
        form = ContactForm(request.POST)

        if form.is_valid():
            form.save()
            return redirect("success")
    else:
        form = ContactForm()

    return render(request, "contact.html", {"form": form})

This is a common pattern in Django. If the request is POST, the form is created using submitted data. If the data is valid, the form is saved or processed. If the request is GET, an empty form is displayed.

The template might include:

1
2
3
4
5

<form method="post">
    
    
    <button type="submit">Send</button>
</form>

The tag is important because Django protects POST forms from cross-site request forgery attacks. This is one of the many built-in security features that make Django reliable for production applications.

A full article on csrf_token can be found here: csrf_token in Django forms

Working with Models

Most Django applications interact with a database through models. Function-based views can query models, create records, update data, or delete objects.

For example, a view that displays a list of blog posts might look like this:

1
2
3
4
5
6

from django.shortcuts import render
from .models import Post

def post_list(request):
    posts = Post.objects.all()
    return render(request, "post_list.html", {"posts": posts})

A detail view for a single post could use Django’s get_object_or_404() shortcut:

1
2
3
4
5
6

from django.shortcuts import render, get_object_or_404
from .models import Post

def post_detail(request, post_id):
    post = get_object_or_404(Post, id=post_id)
    return render(request, "post_detail.html", {"post": post})

The get_object_or_404() function attempts to retrieve the object from the database. If no matching object exists, Django automatically returns a 404 error page. This keeps the code concise and avoids unnecessary error-handling boilerplate.

Redirects in Function-Based Views

A function-based view does not always need to render a template. Sometimes it should redirect the user to another URL. Django provides the redirect() shortcut for this purpose.

1
2
3
4

from django.shortcuts import redirect

def go_home(request):
    return redirect("home")

Redirects are commonly used after successful form submissions. This pattern is known as POST/Redirect/GET. It prevents duplicate form submissions when users refresh the page after submitting a form.

Advantages of Function-Based Views

Function-based views have several important advantages:

1. They are simple. A function-based view is just a Python function. This makes FBVs easy to read, write, test, and debug. Beginners often find them easier to understand than class-based views because there is less hidden behavior.
2. they are explicit. The control flow is visible in one place. If a view handles GET, POST, permissions, form validation, and redirects, the developer can see that logic directly.
3. They are flexible. Function-based views do not force a particular structure. This is useful when a view has unusual business logic or does not fit neatly into a generic class-based pattern.
4. They are excellent for small and medium-sized features. Many web pages do not require complex inheritance or reusable behavior. For these pages, a function-based view is often the cleanest solution.

Disadvantages of Function-Based Views

Function-based views also have limitations:

1. They can become repetitive. For example, many views follow the same pattern: retrieve an object, display a form, validate submitted data, save the object, and redirect. If many views repeat this logic, class-based views or reusable helper functions may reduce duplication.
2. Large FBVs can become difficult to maintain. If a function handles too many responsibilities, it may grow long and complex. In such cases, developers should refactor the code by moving business logic into services, model methods, form methods, or helper functions.
3. Function-based views also do not provide the same built-in structure as class-based views. Class-based views organize behavior into methods such as get(), post(), form_valid(), and get_queryset(). This can be useful for larger applications, especially when views share common behavior.

Function-Based Views vs Class-Based Views

The choice between function-based views and class-based views depends on the situation. Function-based views are usually better when the logic is simple, custom, or easier to express procedurally. Class-based views are often better when the application needs reusable patterns, generic CRUD operations, or shared behavior across multiple views.

For example, a simple dashboard page may be clearer as a function-based view. A standard create, update, delete, or list page may be more concise as a class-based generic view.

A good Django developer should understand both styles. Function-based views teach the fundamentals of Django’s request-response cycle, while class-based views provide powerful abstractions for larger projects.

Best Practices for Function-Based Views

To write effective function-based views, developers should keep them focused. A view should coordinate the request and response, but it should not contain too much business logic. Complex operations should be moved into models, forms, managers, or separate service functions.

It is also important to use Django shortcuts such as render(), redirect(), and get_object_or_404() because they make code cleaner and more idiomatic.

Security should never be ignored. Developers should use in forms, check permissions where necessary, validate user input, and avoid trusting raw request data.

Function-based views can also use decorators. For example, Django provides login_required to restrict access to authenticated users:

1
2
3
4
5

from django.contrib.auth.decorators import login_required

@login_required
def dashboard(request):
    return render(request, "dashboard.html")

Decorators are one of the most elegant ways to add behavior to function-based views without making the function itself more complicated.

Function-based views are one of the most important features in Django. They provide a simple, explicit, and flexible way to handle web requests. A function-based view receives a request, performs whatever logic is necessary, and returns a response. This direct model makes FBVs ideal for beginners and still valuable for experienced developers. Although class-based views offer powerful abstractions, function-based views remain a strong choice in many real-world applications. They are especially useful when the view logic is unique, when readability is a priority, or when a developer wants full control over the request-handling process. In short, Django’s function-based views are not just a beginner-friendly feature. They are a practical and professional tool that can be used effectively in projects of any size when applied with care and good design principles.