Welcome @ligmartinis !
Class-based views and Function-based views
In our case, it’s not “either / or”, it’s both.
Keep in mind that CBVs are Python classes. The Django-provided Generic CBVs are only one possible implementation of them. (For example, in addition to the alternatives listed in the earlier responses, there is also django-vanilla-views.)
Those Generic CBVs can also be considered a starting point and not an ending point. They can be extended in a large number of ways.
For example, we have a rather intricate security layer for determining whether the current user can access a particular view. We have implemented this as a mixin.
I also have a set of mixins that cover a couple of common cases that aren’t directly handled by the Django Generic CBVs - one that is designed to handle two models joined by a foreign key (such as “User” and “Profile” combination), and one designed to handle “model and formset”.
We then created a set of classes that include those mixins in their definition, and use those classes in the views as the base classes for our CBVs.
From our perspective, it’s not about “DRY”, it’s about ensuring consistency among the views. (Personally, I think “DRY” tends to be overemphasized.)
All the views being used extend our custom base classes, ensuring that they all implement the same requirements the same way.
On the other hand, not everything needs to be a CBV, and I don’t hesitate to write an FBV if the situation warrants it.
Python / Django journey
I worked with Python for more than 5 years before working with any Python-based web framework, and 10 years before seriously working with Django. (I think the first version of Python I used was something like 1.5 or 1.6, when it was a much simpler language.)
As I was the only one using Python in my job, my resources were books and on-line resources such as the Python mailing lists. I had to read a lot to wrap my head around certain concepts back then - usually with a lot of trial and error and error and error.
In my case, it was by forcing myself to do it. Even if I had bought a book on a particular topic, and felt like I learned what I needed to learn from the book, I would always make it a practice to go back and read the documentation about that same topic.
For me, that accomplishes three objectives:
- Gain familiarity and comfort with how the docs are written and organized. If I think I’ve understood what a book is telling me, seeing how the docs present the same information helps familiarize me with using the docs themselves.
- Gives me a second perspective on the same topic. This tends to help me understand more about a topic, perhaps expanding my comprehension beyond just the direct question I’m encountering.
- Gives me the exposure to other things that either the book doesn’t cover or covers elsewhere. Just scrolling through the docs to find a particular reference will also mean that my eyes scan topic areas that I should be aware of.
(Side note: I have no patience for video tutorials for most programming topics. I find that they’re generally not worth my time.)
I read good code. I look for popular / highly-rated projects and dig in to see if I can understand how they work.
I encourage people to dig into Django itself and read how it implements certain features. (I don’t suggest digging into the ORM as a starting point. It’s not that it’s not good code, but because of the complexity - those modules are some of the most sophisticated Python code that I have ever tried to read. I’d say right now I understand maybe 20% of it.)
Reading the implementation of the CBVs can be quite helpful, and resources such as the Classy class-based views site and the Class-Based Views diagrams can be very helpful with understanding them.