I'd like to ask you if you can clear something up to me. I'm designing a web app powered by Django and I'm also learning about OOP as I go.
From what understand main purpose of class-based views is to keep my code DRY. To avoid any repetitive or redundant code.
I've tried to implement class-based views however at the end I always ended up tossing everything into function-based view 'coz all the views are fairly unique.
When I looked over the views I asked myself: "Does your code repeat anywhere ?" Answer was no.
The question is: Despite using classed-based views being considered to be the best coding practice it's not always possible. Am I right ?
Class-based views are not inherently better than function-based views. In many cases it's a matter of preference. However, as you get further along in Django you will see that many of the features you'll be using are used in the same view (loading a template, for example) and you may find it easier to modify or extend an existing default CBV than writing a brand-new function every time.
Your question will probably be closed as opinion-based, but I recommend taking what you have over to the Code Review Stack Exchange and getting some feedback there.
https://simpleisbetterthancomplex.com/article/2017/03/21/class-based-views-vs-function-based-views.html
Related
I'm learning Django and I've finished 2 tutorials - official and amazing tutorial called Tango With Django. Though, I got everything I need to work, I have one question:
In Tango with Django aren't used class-based views - only links to the official tutorial.
Why didn't they include this information?
When should we use class-based views and is it a good practice?
Class based views allow you to structure your views and reuse code by harnessing inheritance and mixins.
https://docs.djangoproject.com/en/1.8/topics/class-based-views/
For example you can inherit from "TemplateView" class which provides some features that you may need to use in your own view. For example you can reuse "get" method.
# some_app/views.py
from django.views.generic import TemplateView
class AboutView(TemplateView):
template_name = "about.html"
We use class based views (CBV's) to reduce the amount of code required to do repetitive tasks such as rendering a form or a template, listing the items from a queryset etc.
Using CBV's drastically reduces the amount of code required and should be used where it can be.
It is good to be used in a CRM system. You have a a list view, item view, delete view etc, such as an blog. CBV could help you write less code.
But also because it has do too much for you. Sometimes it will be a little bit troublesome to make some customization or add some extra logic. In this situation, it is more suitable for those really experienced and familiar with CBV so that they could change it easily.
This issue has been tormenting me for a while already. I've read about this topic but nothing seems to clear my thoughts. I understand that they call the views templates, and the models models as well, what I don't really get is where the controllers are. What django calls views seem to me more like actions/methods/functions of a controller than a controller itself, but anywhere I read, I find that supposed view-controller equivalency.
I've worked with MVC frameworks before (ASP.NET MVC3, Ruby on Rails, PHP Laravel Framework), and they all define the controllers as the same thing: a bunch of functions related to a specific topic of the site, namely user accounts or something like that. The best equivalency that I find between this description and django features are the apps, but of course I'm wrong due to the huge amount of people and documentation going the other way.
Could anybody help me with this? Does my mindset make any sense? Am I missing something essential here and then I can't get these concepts right?
It's a mistake to think of design patterns like MVC as unbreakable rules. They really aren't: there are all sorts of ways of implementing them, which comply with the description to a greater or lesser extent.
This is especially the case in Python, where one of the guiding principles is "practicality beats purity" - in other words, do what works.
In any case, Django makes no claim to be an MVC framework. On the contrary, the documentation describes it as MTV: model, template, view. After all, outside the world of design patterns everyone calls "an HTML file with syntax for variables and flow control" a template, not a view.
(That FAQ entry also offers a possible answer to your question: the controller is the framework itself. But it goes on to emphasise that it's a mistake to try to shoehorn into these definitions.)
The views.py defines the view functions for your app and your app groups related functions together.
However what I believe you're missing here is the urls.py.
The urls file is the first part of the controller.
The URL patterns inside urls.py dictates what you're allowed to pass in to the view function or view class (depending on what approach you took, either with function based views or class based views) and then routes it to the proper view function.
So there's tight a coupling between the views.py and the urls.py, that makes up for the entire Controller part of MVC.
Comparing it to Rails, would be that the urls.py is a routes.rb and the actual controller class is the views.py function/cbv.
The mismatch of terminology is unfortunate but more or less doing the same thing.
You can read the Django FAQ. It explains the how MVC is implemented in django. Regarding controller Django has an answer as:
.
Where does the “controller” fit in, then? In Django’s case, it’s probably the framework itself: the machinery that sends a request to the appropriate view, according to the Django URL configuration.
Could anybody help me with this? Does my mindset make any sense? Am I missing something essential here and then I can't get these concepts right?
The only well-defined parts of MVC where nearly everyone had some sort of consensus is the M; the V and C means completely different things in different web frameworks, to the point where MVC framework really only means as not having all your code in one spaghetti (ala typical classical PHP code). You just had to accept that MVC isn't a really well defined term.
Django is not strictly speaking MVC.
I found this discussion very enlightening:
Django is not MVC
Realy guys:
DJANGO is MVC!
But word View use for Controller.
And Django is Full MVC, but
Model - Model
View - Template
Comtroller - View
Apologies if this has been discussed before, have searched and searched but didn't find anything useful :)
But here goes.
We're currently in the process of rewriting a portion of our webapp. Our app is rather old and therefore suffers from some rather cowboy'ish approaches to programming, conventions and urls.
What we're looking for is a simple clean way to design our views and urls so that we can maintain both easier in the future.
The problem is; as of now our urls.py file for the main site is one big mess. a lot of urls that point to a unique view that only does one thin.
Ex. list_books/, edit_book/ etc.
when it comes to specific formats etc. we have something like list_books_json/
(these aren't the actual urls though, but just used to prove a point since the real urls are much worse)
What we want to do now is clean it up a bit. And we we're wondering what the best way to get around it would be??
What we have thought of so far(after reading a lot of things on the subject):
We've thought of designing our urls after the following pattern:
domain/object/action/
so the urls for the apps "staff" site for changing books in the app would be:
staff/books - to view all books (GET)
staff/books/ID - to view one books (GET)
staff/books/new - to create a new book (POST)
staff/books/ID/edit - to edit specific books (POST)
staff/books/ID/delete - to delete specific books (POST)
The thought was then to have only 1 view, views.staff_books() to handle all these actions when dealing with books through the "staff" part of the site.
so that staff_books() checks for ID or a certain "action" (edit, new, delete etc.)
The result would be fewer, but a lot larger views that have to handle all aspects of staff/books. Right now we have a ton of small views that handle only one thing.
Does this makes sense, can you see potential problems? How do you guys go about it??
One place where I think we're lost is in regards to formats.
Where would you put ex. the request for returning the response in json?
we're wondering "staff/books.json" or "staff/books/ID.json" etc. and then keeping all the json logic in the same "staff_books()" view.
So thats it basically. I'm sorry the question is a little "fluffy"... We basically need some examples or good design advice as to how to structure urls and views.
Kind Regards
pete
As an extension (and solution) to your problem I would suggest to use the strategy pattern. Since you already have a structure and the only thing that differs is "how" it is supposed to be carried out, this pattern fits your problem perfectly. What I mean by that is the following:
Create a view which is your entry point to your application with functions named as your url-based functionality (edit, new, delete etc.). I.e where your url.py determines where to go from there.
Create classes which do your stuff based on your domains etc. Lets call them Book, Calendar etc for now.
Implement functionality of those classes, like edit, new, delete etc.
in your view then, determine what class to instantiate and call the corresponding function, e.g in View.edit() call domain.edit()
I think that should do it ^^
Hope it helps :D
I accept that the question is a bit subjective, and that it does not pin point at certain technical doubt/query, but i wanted to know.
I am a newbie in django, after 3-4 months of doing apps in django i am trying to dig-down-deep.
I am currently reading a book by James Brennet where he shows how to use generic views, but when i head to https://docs.djangoproject.com/en/dev/topics/ i see generic views are depricated.
From the "best design perspective" point of view, how is using generic views rated?
Is it considered a good practice to use generic views?
If yes why is then django depricating it?
If no, what else is recommended?
Thanks!
The old generic views are deprecated because they've been replaced with 'Class-based generic views':
https://docs.djangoproject.com/en/dev/topics/class-based-views/
If you have a lot of view which repeatedly express the same pattern, for example a set of CReate/Update/Delete (CRUD) views for several models... where most of the view code is the same but just some specifics change, eg the model class and final redirect url... this is where generic views make sense.
The goal is to be DRY (Don't Repeat Yourself) ...ie write the code in one place and re-use, catch and fix bugs in one place etc.
I've begun diving into Django again and I'm having trouble finding the parallel to some common concepts from my life in C#. While using .NET MVC I very often find myself creating a base controller which will provide a base action implementation to take care of the type of stuff I want to do on every request, like retrieving user information, getting localization values.
Where I'm finding myself confused is how to do this in Django. I am getting more familiar with the MVT concept but I can't seem to find how to solve this scenario. I've looked at class based views and the generic views yet they didn't seem to work how I expected. What am I missing? How can i create default logic that each view will be instructed to run but not have to write it in each view method?
If it is truly common for your whole site you use middleware. If it is only common for some views, the way to go in my opinion is to create decorators for those views. I never use class-based views because I tend to keep views simple and put more logic into models, so I have no need for classes there.