Function-based vs class-based decision in Django - Visual Side-by-Side Comparison

Concept Flow - Function-based vs class-based decision

Start Request

↓

Check View Type

↓

Function

↓

Call function

↓

Execute code

↓

Return Response

↓

End

The request first checks if the view is function-based or class-based, then calls the function or instantiates the class and calls its method, finally returning a response.

Execution Sample

Django

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

def my_view(request):
    return HttpResponse('Hello')

class MyView(View):
    def get(self, request):
        return HttpResponse('Hello')

Shows a simple function-based view and a class-based view handling a GET request.

Execution Table

Step	View Type	Action	Details	Response
1	Function-based	Call function	my_view(request) called	None yet
2	Function-based	Execute code	Return HttpResponse('Hello')	HttpResponse with 'Hello'
3	Function-based	Return response	Response sent to client	HttpResponse with 'Hello'
4	Class-based	Instantiate class	MyView() created	None yet
5	Class-based	Call method	MyView.get(request) called	None yet
6	Class-based	Execute code	Return HttpResponse('Hello')	HttpResponse with 'Hello'
7	Class-based	Return response	Response sent to client	HttpResponse with 'Hello'

💡 Execution stops after response is returned to client.

Variable Tracker

Variable	Start	After Step 1	After Step 4	After Step 5	Final
request	HttpRequest object	Passed to my_view	Passed to MyView instance	Passed to get method	Used to create response
response	None	None	None	None	HttpResponse('Hello')

Key Moments - 2 Insights

Why do we instantiate a class in class-based views but not in function-based views?

Because class-based views use methods inside a class, so Django creates an instance to call the method (see execution_table steps 4 and 5). Function-based views are just called directly (steps 1 and 2).

How does the request get handled differently in function vs class-based views?

In function-based views, the request is passed directly to the function. In class-based views, the request is passed to the class instance method (see variable_tracker showing request passed at different steps).

Visual Quiz - 3 Questions

Look at the execution table, at which step is the class instantiated in a class-based view?

A Step 5

B Step 2

C Step 4

D Step 1

💡 Hint

Check the 'Action' column for 'Instantiate class' in the execution_table.

According to the variable tracker, what is the value of 'response' after step 2 in function-based views?

A HttpResponse('Hello')

B None

C HttpRequest object

D MyView instance

💡 Hint

Look at the 'response' row and the 'After Step 2' column in variable_tracker.

If the class-based view did not instantiate the class, what would happen?

A The get method could not be called on an instance

B The function would run normally

C The response would be sent twice

D The request would be ignored

💡 Hint

Refer to key_moments explaining why instantiation is needed before calling methods.

Concept Snapshot

Function-based views are simple functions called directly with the request.
Class-based views are classes instantiated by Django, then their methods handle requests.
Function views are straightforward; class views allow reuse and organization.
Both return HttpResponse objects to send back to the client.
Class-based views require instantiation before method calls.
Choose function views for simplicity, class views for structure.

Full Transcript

This visual execution compares function-based and class-based views in Django. When a request comes in, Django checks if the view is a function or a class. For function-based views, it calls the function directly with the request, executes the code, and returns a response. For class-based views, Django first creates an instance of the view class, then calls the appropriate method (like get) with the request. Both approaches end by returning an HttpResponse to the client. The variable tracker shows how the request and response variables change during execution. Key moments clarify why class instantiation is necessary and how request handling differs. The quiz tests understanding of these steps and concepts.

Practice

1. Which of the following is a key advantage of using class-based views (CBVs) over function-based views (FBVs) in Django?

easy

A. FBVs require less code for complex views.

B. CBVs are always faster than FBVs.

C. FBVs cannot handle POST requests.

D. CBVs allow reuse of common functionality through inheritance.

Solution

1. Step 1: Understand CBVs and inheritance

   Class-based views use classes, so they can inherit and reuse code easily.

2. Step 2: Compare with FBVs

   Function-based views are simple functions and do not support inheritance for reuse.

3. Final Answer:

   CBVs allow reuse of common functionality through inheritance. -> Option D

4. Quick Check:

   CBVs = reuse by inheritance [OK]

Hint: CBVs use classes, so they support inheritance and reuse [OK]

Common Mistakes:

• Thinking CBVs are always faster
• Believing FBVs can't handle POST
• Assuming FBVs are better for complex views

2. Which of the following is the correct way to define a simple function-based view in Django?

easy

A. def my_view(request): return HttpResponse('Hello')

B. class my_view(View): return HttpResponse('Hello')

C. def my_view(): return HttpResponse('Hello')

D. class my_view: def get(): return HttpResponse('Hello')

Solution

1. Step 1: Check function signature for FBV

   A function-based view must accept a request parameter.

2. Step 2: Validate return statement

   The function should return an HttpResponse object.

3. Final Answer:

   def my_view(request): return HttpResponse('Hello') -> Option A

4. Quick Check:

   FBV needs request param and returns HttpResponse [OK]

Hint: FBVs are functions with request parameter returning HttpResponse [OK]

Common Mistakes:

• Omitting the request parameter
• Using class syntax for FBV
• Not returning HttpResponse

3. Given this class-based view code, what will be the HTTP response content when a GET request is made?

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

class HelloView(View):
    def get(self, request):
        return HttpResponse('Hello from CBV')

medium

A. HelloView object

B. Hello from CBV

C. Error: get method missing request

D. Empty response

Solution

1. Step 1: Identify the get method behavior

   The get method returns HttpResponse with 'Hello from CBV'.

2. Step 2: Understand request handling

   A GET request calls the get method and returns that response content.

3. Final Answer:

   Hello from CBV -> Option B

4. Quick Check:

   GET calls get() returning 'Hello from CBV' [OK]

Hint: GET calls get() method in CBV returning its HttpResponse [OK]

Common Mistakes:

• Confusing class name with response content
• Thinking get method lacks request parameter
• Expecting empty or error response

4. What is wrong with this function-based view code?

def my_view():
    return HttpResponse('Hi')

medium

A. Function name must be capitalized.

B. HttpResponse cannot be returned from a function.

C. Missing request parameter in function definition.

D. The return statement should be inside a class.

Solution

1. Step 1: Check function parameters

   Function-based views must accept a request parameter to receive HTTP requests.

2. Step 2: Validate function signature

   The given function lacks the required request parameter, causing errors.

3. Final Answer:

   Missing request parameter in function definition. -> Option C

4. Quick Check:

   FBV needs request param [OK]

Hint: FBVs always need request parameter [OK]

Common Mistakes:

• Ignoring missing request parameter
• Thinking HttpResponse can't be returned
• Believing function names must be capitalized

5. You want to create a Django view that handles GET and POST requests differently and also reuse some common code for multiple views. Which approach is best?

hard

A. Use class-based views with methods for GET and POST and inheritance for reuse.

B. Use class-based views but define all logic in a single method.

C. Use function-based views with if-else inside to check request method.

D. Use function-based views with decorators for GET and POST.

Solution

1. Step 1: Identify need for handling GET and POST separately

   Class-based views allow defining separate get() and post() methods for clarity.

2. Step 2: Consider code reuse

   CBVs support inheritance, so common code can be reused across multiple views easily.

3. Final Answer:

   Use class-based views with methods for GET and POST and inheritance for reuse. -> Option A

4. Quick Check:

   CBVs = separate methods + reuse [OK]

Hint: CBVs separate methods and support inheritance for reuse [OK]

Common Mistakes:

• Using FBVs with complex if-else for methods
• Putting all logic in one CBV method
• Ignoring inheritance benefits