Django and MVC
Before we dive into Django and MVC, we need to first explain how web applications are fundamentally different from Desktop applications. In a desktop application, we typically run a program on one computer for one user, and when the user is done, they close the application. Data is often persisted (“saved”) locally on the computer. In a very simple desktop application, there may be no user interaction at all beyond perhaps some command-line arguments. In that case, the program runs until it completes, and then terminates.
However, with web applications, we typically want a persistent application that is driven by asynchronous events. That is, we cannot predict precisely when and how users will interact with our webservice, and so we don’t try. In modern web application development, we strive for statelessness.
In a stateless web application, the web server doesn’t store any information about a user’s state on the server memory. Rather, as the user uses the website, each URL acts as sort of a “functional call” that modifies the websites long-term storage (database).
As an example of this, open amazon.com and add some book to your shopping cart (might I suggest Clean Code by Robert Martin. Now, close your browser, and open amazon.com on your phone or another device, log-in, and you’ll see the same item in your cart.
That’s because, when using Amazon before, your cart wasn’t tied to any state of your web browser communicating with Amazon’s servers. Rather, adding a book to your cart was a transaction. That transaction was recorded in the website’s database, not stored in the server’s memory.
Now compare this with older websites Collab and SIS. Both websites rely on “stateful” context connections:
CLASSROSTER$1, but that
$1 indicates (in the above example) the class at index 1 in the courses table. That means this function only works because of the context. So, if we were to open that roster, copy the web-url, closer our browser, and then re-open and paste, it wouldn’t take us to the same place. That’s because this website is relying on the context (or “state”) the user is in. This contributes to several issues with Collab and SIS. Namely:
Now we’re ready to talk about MVC. MVC (Model-view-controller) has become extremely widely adopted in application development (both for web applications and GUI applications). MVC has three components:
View - the portion of the system that handles creating and rendering the user interface. Whether this is generating HTML pages, creating dynamic user interfaces with buttons, fields, etc., or simply returning raw data using something like JSON, any “output” of the application is rendered by the view.
This gives us the benefit of separation of concerns, and helps us to write reusable code.
In this section, we will give a very brief overview of Django structure. A full tutorial can be found here.
Django is an MVC framework, although they use the nomenclature model/view/template. As such,
views.py ends up being what we would think of as the Controller, and not the View.
Within a given app, we have the following files and folders:
models.py - The model lists our ORM (Object relational model classes) - One advantage of Django is that Django will handle all the database interactions (SQL queries, for example) for you. You only have to define your data classes in
views.py - The controller (not the view) - lists a menu of functionalities of the website. This could include things like “display a web page with all of the survey questions” or “display the results for this particular survey question”. Some of the options may perform invisible interactions without displaying their own webpage (such as the function
vote from the Django tutorial)
urls.py - Connects the urls the user interacts with the the functions and classes in
views.py. You can think of
urls.py as a traffic cop, that directs requests from users (which come in via urls) to the correct
views.py function or class.
templates/[appname] - The view - this folder contains the .html template files that are used to generate the web pages users receive back from the server. The actual code that builds these web pages from the templates and data provided by the controller is handled by the Django framework itself. As such, you only need to define a template for the .html page.