Django is a Loosely Coupled Framework

If you can indulge me a minute, and purge your brain of your favorite Three Letter Acronyms (TLAs), there’s an easier way to understand this.

The first step is to understand that Django is not the result of an academic exercise, nor is it some guru’s idea of cool—Django’s creators designed Django to solve a particular set of problems in a busy and complex news organization. At the center of this set of problems were three very different needs:

  1. The data guys (and gals) needed a common interface to work with disparate data sources, formats and database software.
  2. The design teams needed to manage the user experience with the tools they already had (HTML, CSS, JavaScript etc.).
  3. The hard-core coders required a framework that allowed them to deploy system changes rapidly and keep everyone happy.

Crucial to making this all work was ensuring each of these core components—data, design and business logic—could be managed independently, or to use the correct computer parlance—the framework had to employ loose coupling.

Now, it’s important to understand that I’m not trying to say Django is doing anything magic or new here, nor were the problems Django’s creators faced unique. The creators of Django are brilliant guys, and they certainly knew MVC was a well-established design pattern that would help solve their problems.

My point is it’s highly unlikely any of them ever said, “Hang on boys, we need to change this code because Wikipedia says a controller should …”.

You need not get hung up on semantics—you can safely forget about the confusing TLAs and whether Django is like Framework X and concentrate on what Django is.

Django’s architecture comprises three major parts:

  • Part 1 is a set of tools that make working with data and databases much easier.
  • Part 2 is a plain-text template system suitable for non-programmers; and
  • Part 3 is a framework that handles communication between the user and the database and automates many of the painful parts of managing a complex website.

Parts 1 and 2 are instantly relatable (see Figure 3.1):

  • Django Models are the tools we use to work with data and databases; and
  • Django Templates provide a designer-friendly plain-text template system.

But what about Part 3? I hear you ask, isn’t that the controller, or a Django view?

Well, no. Which leads me to heresy #2: