alt Hacker NewsClass-based views were a problem when they were introduced in Django, and they’re still a problem.
Especially for the so-called AI-ready framework. Because of indirection, you either have to go read all the basic classes, or read documentation three times over. Instead of just reading the self-contained view function itself, once.
Especially true for an agent, it will have to go read the new framework’s docs and source over and over and over…
Replies
drchaim • last Wednesday at 7:15 AM
that's so true, I still prefer function based views
There are very specific reasons to use Django’s class-based views, so much so that it doesn’t really strike me as “multiple ways to do one thing”.
Case 1. You are simply writing a view. Request comes from the router, you want to run some logic and return a response. Either it is part of the end project, or it is simple and small enough that the end project would prefer to just override the entire thing. Write a function!
Case 2. You are working on an end project, and you want to take a view shipped by Django or some library and override bits of its behaviour. The view is already shipped as a class, and writing it as a function would be unwieldy because there is a bunch of logic you’d need to repeat. No-brainer: just inherit and go.
Case 3. You are writing a library that is intended to be customised by the end project. You ship a view that performs a somewhat complex sequence of actions as part of handling a request (e.g., validating input, constructing a query, fetching a QuerySet, serializing it in some way). You want to give the end project an easy way to borrow your view and override only specific parts of that logic. Consider writing a class-based view, and basing it on some pre-existing class-based view if possible (the above looks a bit like ListView, for example).