Django is a web framework written in Python. It was first released by Adrian Holovaty and Simon Willison in 2005. Django framework is now operated under the guidance of the Django software foundation. It is one of the most famous open-source projects.
Django is one of the best web frameworks out there and it’s loved by thousands of developers. The reason for its popularity is its clean architecture, speedy development environment, and ease of use. Django follows some industry-standard set of design principles.
Django framework design principles
We can produce the same results with any web framework and programming language. But what will vary drastically is the time we spend creating a solution, the time creating a prototype, the time adding new features, the time doing testing, the time doing debugging, deploying to scale, and so many other things.
Django is one of the most productive frameworks for building and scaling medium to large web applications.
Let’s talk briefly about the design principles that give Django this edge over other frameworks.
DRY (Don’t repeat yourself) principle
There is a very popular design principle called DRY which stands for Don’t Repeat Yourself. It’s a basic principle of software development aimed at reducing the repetition of information.
The DRY principle is stated as, “Every piece of knowledge or logic must have a single, unambiguous representation within a system.”
In web development, we have to work with multi-tier logic interacting with each other. In these situations, repetition of code is very common. Django tries really hard to deal with these situations by imposing DRY design principles.
Let’s assume that we want to build a very basic user sign-up app. first, we have to determine what information we want from the user. Then, in Django, we have to set up the model for the app.
name = models.CharField(max_length=30) email = models.EmailField() address = models.CharField(max_length=30)
Here we can see that the model has different fields and data types so the values are restricted. For example,
name = models.CharField(max_length=30)
This code tells Django that names shouldn’t be more than 30 characters long.
email = models.EmailField()
tells Django the contact entity should contain a valid email value.
In an ideal web application, we have to implement the following:
- Create relational database tables to save entity information.
- Create HTML forms to allow data to be submitted.
- Create an admin dashboard.
- Create business logic for the requirements.
- Create REST services to expose the API.
In doing so we have the potential of repeating dozens of similar pieces of information in database definition language (DDL), HTML forms, business logic, etc, among other things. A process that’s time-consuming and error-prone. repetition of code is inevitable here. Not to mention these tasks are grueling themselves.
What if we didn’t have to do any of it? What if based on statements like
models.CharField(max_length=30)
Django could generate a DDL statement and HTML form input, validate information to only contain 30 characters and create an admin interface. That’s exactly what Django does.
A REST API could be easily created using Django Rest Framework from the model.
Thus instead of reinventing the wheel, Django eases the development process
By providing the boilerplate code.
Explicit is better than implicit
One of the “zen” of python is “ Explicit is better than implicit”. Django follows this mantra of python.
Code written by other developers has always been a mystery to us. And if these codes are ambiguous and constructed to their whims it becomes unreadable. So an open-source project needs to follow some rules and architecture while writing code so that everyone could easily understand what’s going on. Adding a new feature or understanding the logic behind some piece of code becomes easy. Explicit requires a little more typing, but in the end, it’s well worth it comparing it to the potential effort you can face trying to debug or solve a problem.
Django has a huge codebase but it’s very easy to read and understand what each piece of code doing because of its clean architecture and explicit style. Let’s compare two pieces of code written in ruby on rails and Django implementing a piece of “view” in the MVC pattern.
Ruby on rails code: class StoresController < ApplicationController def show # Automatic access to params, a ruby hash with request parameters, and view parameters @store = Store.find(params[:id]) # Instance variables like @store are automatically passed on to view the template # Automatically uses template views/stores/show.html.erb end
the code behavior is very implicit. And if we implement the same logic in Django :
# Explicit request variable contains request parameters
# Other view parameters must be explicitly passed to views
def detail(request, store_id):
store = Store.objects.get(id=store_id)
# Instance variables must be explicitly passed on to a view template
# Explicit template must be assigned
return render(request, 'stores/detail.html', {'store': store})
As you can see there is no magic here. Last snippet we don’t have to guess where the input parameter is coming from. They are explicitly declared as arguments.
like in Python, the Django framework will always favor an explicit approach over any implicit technique.
Loosely coupled architecture
Django official docs say,
“ A fundamental goal of Django’s stack is loose coupling and tight cohesion. The various layers of the framework shouldn’t “know” about each other unless necessary.”
Django follows the MVC pattern and it’s very flexible to work with. There’s a concept of “app” in Django. Each app performs different tasks and is independent of each others. These apps are also reusable. Html or also called templates in Django is also independent and can be omitted and Django can just return the raw data ( e.g. REST API).
