A Django View is Not a Controller

Check out Figure 3.1, does it look familiar?

Figure 3.1: The somewhat misleading Django MTV diagram.

This is one of my diagrams, but there are plenty of similar versions out there. A common way of explaining Django’s architecture in terms of MVC is to describe it as a Model-Template-View (MTV) or Model-View-Template (MVT). There’s no difference between MTV and MVT—they’re two different ways to describe the same thing, which adds to the confusion.

The misleading part of this diagram is the view. The view in Django is most often described as being equivalent to the controller in MVC, but it’s not—it’s still the view.

Figure 3.2 is a variation on Figure 3.1 to illustrate my point.

Figure 3.2: A slightly different view of Django’s MTV “stack”.

Note how I have drawn a line between the client- and server-side. Like all client/server architectures, Django uses request and response objects to communicate between the client and the server. As Django is a web framework, we’re talking about HTTP request and response objects.

So, in this simplified process, the view retrieves data from the database via the model, formats it, bundles it up in an HTTP response object and sends it to the client (browser).

In other words, the view presents the model to the client as an HTTP response. This is also the exact definition of the view in MVC, or to quote Wikipedia (not the most definitive source, I know, but close enough):

“The view means presentation of the model in a particular format”

Trying to bend the definition of a Django view to fit a particular viewpoint inevitably leads to one of two things:

1. Confused programmer puts everything in views module; or
2. Confused programmer says “Django is too hard!”, and watches TV instead

So getting away from our M’s and T’s and V’s and C’s, Figure 3.3 presents a more holistic view of Django’s architecture.

Figure 3.3: A more holistic view of Django’s architecture.

The first point of confusion we can clear up is where to put a particular function or class:

Does the function/class return a response?

• YES—it’s a view. Put it in the views module (views.py).
• NO—it’s not a view, it’s app logic. Put it somewhere else (somewhere_else.py).

We’ll discuss the somewhere else part in the next section of this chapter.

The next point to note is that the Django framework encapsulates the model, view logic and business logic. In some tutorials, it’s said that the Django framework is the controller, but that isn’t true either—the Django framework can do much more than respond to user input and interact with data.

A perfect example of this extra power is Django’s middleware, which sits between the view and the client-side. Django’s middleware performs critical security and authentication checks before sending the response to the browser.

So, returning to the two confused responses from the beginning of the chapter:

1. Beginners—no, you don’t have to learn about MVC because it’s more than likely going to confuse you and lead to more questions than answers
2. Programmers—no, Django is not like Framework X, and trying to think it is, is likely to confuse you and lead to more questions than answers

Now we’ve got that out of the way, let’s have a look at the structure of a Django project.