That is the question to be asked!

When Django’s class-based views first arrived on the scene back in 1.3 they were initially somewhat controversial. It took a few years and a few major releases until acceptance approached critical mass to the point where at least most new Django developers I’ve talked to are using class-based views by default. Compared to plain view functions, class-based views allow for greater reuse, standardization, and piggy backing on both of these, a lot of off-the-shelf solutions for standard view uses cases.

There are pros and cons to using either style to create views in a new project, but we want to focus on approaching a project that already has a set of views.

Is it worth changing from one style to the other? How should you go about creating additional views?

(The earliest known consideration of whether or not to use CBVs)

You’re going to love the answer…

…because as usual, the answer is it depends.

A reasonable guideline, holding all other things equal, is to follow a consistent style if there is one. If the project uses functional views, use functional views, and if it uses class-based views, use class-based views. Again, all things being equal.

First put your views on a diet

If you’re looking at making changes to the views in an existing codebase, first you gotta do some maintenance. The choice of what kind of view to use should be preceded by first cleaning up the existing views in their current style. I have not yet come across a project in which some portion of the views couldn’t be cleaned up by replacing inline code with shortcuts and large blocks of business logic with separate functions, better model and manager methods, and even form classes.

Many gnarly looking view functions work fine when their dozens of lines of code are stripped out to more applicable functions and classes, and more than a few view classes have been found to be little more than lengthy abuses of single response functions.

The goal is not to remove everything from the views, but to make them as skinny as reasonably possible before assessing how to restructure them.

When to restructure view styles

Consistency of style is a rule of thumb - it makes the code easier to read, allows sharing of functionality through decorators or mixins, respectively - but let it not be a foolish one.

1. If the views are simple enough and can better make use of shared functionality, it may be worth refactoring the view styles
2. If testing in one way or the other is simpler (without sacrificing code readability and maintainability), it may be worth refactoring the view styles I’ll share my thoughts some other time on the benefits of each style, but if you must refactor one way or another for maintainability CBVs are your best bet. Despite the occasional hiccups from misunderstanding the method resolution order[1], most other developers will find understanding the more structured style of CBVs to the more flexible style of functional views especially when coupled with extensive or creative use of decorators.

The bottom line though is that there’s a lot you can do to make your views easier to understand, easier to test, and even to work better before you start changing from functional to class-based, or vice versa.

Happy refactoring,
Ben

[1] See Raymond Hettinger’s 2015 PyCon talk, Super considered super!

More like this

• This Old Pony: The Surprising Power of Linting
• This Old Pony: "...the old man knows the exceptions."