FAQ on Model-View-Controller

[Dan S]

The Django FAQ says:

 

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?¶

Well, the standard names are debatable.

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.

So, in our case, a “view” is the Python callback function for a particular URL, because that callback function describes which data is presented.

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.

At the end of the day, of course, it comes down to getting stuff done. And, regardless of how things are named, Django gets stuff done in a way that’s most logical to us.

Sorry, but the standard names are not debatable, the developers have simply chosen to misuse terms that have well-accepted definitions.   A Controller is something that manipulates the model, not something that performs one step or a different step of viewing the model.  For example, in a payroll application the model would contain records for employees' time and attendance and records for W-2 tax statements.  A View for a W-2 statement is certainly a Python callback to pull data from the model, as well as a template to present the W-2 to the user on the screen.   But a View cannot create a W-2 record in the database - that is the job of a Controller, which takes employee records containing SSN and salary, timesheet records containing hours worked, and information derived from tax laws and creates the W-2 records.

Instead of claiming that MVC terms can be debated or redefined, the FAQ should state that Django supports the MVC design pattern, that it provides two elements (views.py and templates.html) that support the View component, and that developers create their own business logic to implement Controller elements that produce model data.  In journalism staff people creating articles and the public commenting on articles are sort of acting as controllers, but in most domains the computer plays a more central controller role - translating the position of the foot on an accelerator pedal into the amount of gas and air injected into an engine, or translating employee data into tax data.

[Aymeric Augustin]

Hello Dan,

Depending on the size and complexity of a Django project, there are two ways to implement MVC. (I’m talking of a traditional Django project, not Django-as-an-API-for-a-JS-app.)

1) Small project: the straightforward way

M = models.py

V = template.html

C = thick views.py: most of the application is implemented there

2) Large project: the scalable way

M = Django models, other data stores, various APIs, with ad-hoc mechanisms to ensure consistency

V = thin views.py: business logic gets pushed out to other layers for testability + template.html

C = a custom abstraction layer: most of the application is implemented there

The FAQ was written 10 years ago when (1) was the dominant pattern and (2) hadn’t been formalized as a best practice for large projects.

If I understand correctly you’re advocating for (2). Perhaps we can improve this FAQ entry but (1) remains a perfectly valid way to write simple applications.

-- 

Aymeric.

PS: in case you didn’t realize it, your email is worded in a rather aggressive way. Saying hello and being polite wouldn’t hurt your credibility, on the contrary. Thanks!

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/274923c2-99f5-4013-8914-0f7142d15f78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dan S]

Hello Aymeric,

I apologize for using an aggressive tone, it is not my intent to insult anyone, just to request that content be updated.   xkcd/386 on the other hand makes it personal, referring to some*one*, not some*thing* :-)

I suppose I intended to say that MVC is not defined within the context of a Django project, large or small.   In the context of the English language, and engineering practice, and even <humor> the unimpeachable source Wikipedia </humor>, a controller controls (makes changes to) a thing, while a view provides a particular vantage point (one of many) for observing that thing without changing it.

I am an old Django newbie working on a small project, and because the only hooks for Python code I've discovered so far are in views.py, that file necessarily touches both V and C code.  I've tried to keep them separate, retaining all the template-driving code in views.py and pushing all model-updating code (the interesting part of my project) into different modules.   So I suppose I have discovered your large project approach without even knowing there was a distinction or needing to use more than a single datastore.  The data-model-centric design of Django makes it hugely attractive to me regardless of any quibbles over where V and C get instantiated.

So I humbly suggest that the wording of the FAQ be adjusted to make clear that the "meaning" of V and C are not debatable, that templates and template-feeding code always serve the purpose of Viewing the model, and that Controller code can be either included in views.py or refactored elsewhere.

Dan

[Aymeric Augustin]

Hi Dan,

On 8 août 2015, at 18:03, Dan S <dms...@outlook.com> wrote:
> So I humbly suggest that the wording of the FAQ be adjusted to make clear that the "meaning" of V and C are not debatable, that templates and template-feeding code always serve the purpose of Viewing the model, and that Controller code can be either included in views.py or refactored elsewhere.

I agree. The frontier between V and C can be muddy in Django projects. Depending on how you organize your code the frontier between M and C can become unclear as well.

This FAQ already acknowledges that Django isn’t really a MVC framework, that a Django “view” isn’t “V” and that there’s no well-defined equivalent of “C”. At the time it was written, perhaps MVC was a mandatory item on a web framework’s feature list. By now, we don’t need to shoehorn Django into MVC concepts anymore.

We could say “in Django parlance” instead of “in our interpretation of MVC” and just accept that we aren’t adhering to MVC as it was originally defined. That should clear misunderstandings.

--
Aymeric.

[Tim Graham]

Dan, please offer a pull request if you are able.