Class-Based Views vs. Function-Based Views
There was a time that function-based generic views was a thing. They were created to address the common use cases. But the problem was that they were quite simple, and was very hard to extend or customize them (other than using configurations parameters).
To address those issues, the class-based views was created.
Now, views are always functions. Even class-based views.
When we add them to the URL conf using the View.as_view() class method, it returns a function.
Here is what the as_view method looks like:
So if you want to explicitly call a class-based view here is what you need to do:
To make it feel more natural, you can assign it to a variable:
The view function returned by the as_view() method is outer part of every class-based view. After called, the view pass the request to the dispatch() method, which will execute the appropriate method accordingly to the request type (GET, POST, PUT, etc).
Class-Based View Example
For example, if you created a view extending the django.views.View base class, the dispatch() method will handle the HTTP method logic. If the request is a POST, it will execute the post() method inside the view, if the request is a GET, it will execute the get() method inside the view.
views.py
urls.py
Function-Based View Example
In function-based views, this logic is handled with if statements:
views.py
urls.py
Those are the main differences between function-based views and class-based views. Now, Django’s generic class-based views are a different story.
Generic Class-Based Views
The generic class-based-views was introduced to address the common use cases in a Web application, such as creating new objects, form handling, list views, pagination, archive views and so on.
They come in the Django core, and you can implement them from the module django.views.generic.
They are great and can speed up the development process.
Here is an overview of the available views:
Simple Generic Views
- View
- TemplateView
- RedirectView
Detail Views
- DetailView
List Views
- ListView
Editing Views
- FormView
- CreateView
- UpdateView
- DeleteView
Date-Based Views
- ArchiveIndexView
- YearArchiveView
- MonthArchiveView
- WeekArchiveView
- DayArchiveView
- TodayArchiveView
- DateDetailView
You can find more details about each implementation in the official docs: Built-in class-based views API.
Pros and Cons
For reference, some pros and cons about function-based views and class-based views.
Pros Of Function-Based Views
- Simple to implement
- Easy to read
- Explicit code flow
- Straightforward usage of decorators
Cons Of Function-Based Views
- Hard to extend and reuse the code
- Handling of HTTP methods via conditional branching
Pros Of Class-Based Views
- Can be easily extended, reuse code
- Can use O.O techniques such as mixins (multiple inheritance)
- Handling of HTTP methods by separate class methods
- Built-in generic class-based views
Cons Of Class-Based Views
- Harder to read
- Implicit code flow
- Hidden code in parent classes, mixins
- Use of view decorators require extra import, or method override
There are cases where function-based views are better. In other cases class-based views are better.
For example, if you are implementing a list view, and you can get it working just by subclassing the ListView and overriding the attributes. Great. Go for it.
Now, if you are performing a more complex operation, handling multiple forms at once, a function-based view will serve you better.
For better understanding you can check here.
Thank you people for your valuable time.Happy reading