Django vs. Model View Controller

The Django FAQ itself is a decent place to start:

• https://docs.djangoproject.com/en/dev/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names

In our interpretation of MVC, the “view” describes the data that gets presented to the user. It’s not necessarily how the data looks, but which data is presented. The view describes which data you see, not how you see it. It’s a subtle distinction.

...

Furthermore, it’s sensible to separate content from presentation – which is where templates come in. In Django, a “view” describes which data is presented, but a view normally delegates to a template, which describes how the data is presented.

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.

If you’re hungry for acronyms, you might say that Django is a “MTV” framework – that is, “model”, “template”, and “view.” That breakdown makes much more sense.

Bear in mind that “Model View Controller” is just a pattern, i.e. an attempt to describe a common architecture. So a better question might be “How well does Django fit the Model View Controller pattern?”

According to the Django Book, Django follows the MVC pattern closely enough to be called an MVC framework.

Django has been referred to as an MTV framework because the controller is handled by the framework itself and most of the excitement happens in models, templates and views.

You can read more about MTV / MVC here:

The MTV (or MVC) Development Pattern

If you’re familiar with other MVC Web-development frameworks, such as Ruby on Rails, you may consider Django views to be the controllers and Django templates to be the views.

This is an unfortunate confusion brought about by differing interpretations of MVC.

In Django’s interpretation of MVC, the view describes the data that gets presented to the user; it’s not necessarily just how the data looks, but which data is presented.

In contrast, Ruby on Rails and similar frameworks suggest that the controller’s job includes deciding which data gets presented to the user, whereas the view is strictly how the data looks, not which data is presented.