Our Secret to Object-Relational Mapping

Django CMS.jpeg

The Problem Space

An ongoing concern in software development is the incongruity that exists between the relational data structures (RDS) of databases and the object-oriented nature of the majority of modern code. For example, the relational state does not propagate within the scope of the objects that reference each other in many-to-many and one-to-many relationships in an RDS, as would be expected in an objected-oriented model. Sound familiar?

This is known as the Object-Relational-Mapping (ORM) problem. At Level 11, we use Django to deal with ORM.

Why Django?

Django is a Python framework which allows us to quickly create, manage, and evolve an ORM interface to a database. Here, we will briefly discuss what makes Django so useful.

One of the core strengths of Django is its rigorous application of the DRY principles (Do not Repeat Yourself). In practice, code should address any given concern only once, leading to an effective expression of the code, and the reduction of inconsistent redundancies.

Django, along with its companion Django Rest Framework (DRF), addresses the full stack of functionality required for developing a Web or Restful application by using a declarative programming paradigm. Specifically, this is done through minimal configuration of the following categories of object types:

  • Data Model;
  • Serializers;
  • Views;
  • Uniform Resource Locator (URL);
  • And the User Interface (UI).

The Data Model

The model represents the core location where the data is defined as designed in the Entity-Relationship Model (ERM) and handles entity attributes and foreign-key-based relations. The translation of this information into an actual SQL interaction with the Relational Database Management System (RDBMS) is actually handled by Django.

The Django language provides constructs in Python that allow the software engineer to program explicit interactions with the database, entirely bypassing the need to code in SQL. It also handles modifications of the data model which occur as the project evolves by generating Django code (Python) that can apply the desired modifications, referred to as migrations.


The ORM model is aligned more to the concepts of serialization than it is with object-orientation. Serialization controls what is exposed to the client of the API, and Django with DRF are very focused on that aspect of ORM. The model-based serializers work out of the box supporting the CRUD foundation of Restful API, but allow for significant additions and overrides that effectively amount to the definition of complex business methods.


In Django, a view is really a controller, common parlance to anyone who is familiar with MVC web application patterns. The view code declaratively collects references to the data model and serializer and implicitly implements CRUD operations.



The views are referenced in the URL declarations through constructs known as "routers," which are configured by the programmer to provide URL-based access to standard CRUD operations (just like we expect it in REST) and to specialized operations that can be defined in the views.

The User Interface

In most of our applications, we prefer a headless CMS system; however, Django was designed to be a complete implementation of a Content Management System (CMS). This is where we part ways with Django.

There is no doubt the out-of-box configuration of the Django Web UI is simple, reliable, and impressive overall. However, because it so tightly coupled with the data model definition, applications designed with an advanced UI would require changes made directly to the data model. This is not advantageous. At Level 11, our applications require advanced, and highly customizable UI, typically based on REST APIs, so we do not use this Django component.

The above characteristics are the principal reasons we use Django at Level11. Django also features built-in or added-on capabilities to handle database transactions, caching, searching, and security. Our architecture usually requires that we handle these capabilities with Java-based components while Django serves as the ORM database access microservice. This approach provides us with the flexibility and adaptability to changing requirements and aligns with our Level 11 delivery standards.


Tomasz Gil.jpg

About Author

Tomasz Gil is a senior software engineer at Level11 specializing in server-side implementations. He believes that analysis, along with generalization and abstraction, leads to simpler and better software solutions based on the most suitable technologies. Clear articulation of the problem is often half of the work.

David VyPython, Django, Database, ORM