Design Patterns in Django 1.1
Data has been taken from the following Book. https://doc.lagout.org/programmation/Django/Django%20Design%20Patterns%20and%20Best%20Practices%20%5BRavindran%202015-03-26%5D.pdf
I am forwarding the idea of the above book in a summarized manner. For in-depth study follow the book.
A pattern is a kind of regularly occurring structure or repeated design. A pattern is actually a generalized solution for commonly occurring problems. We are surrounded by various kinds of patterns in different fields. One example is given below:
As you can see here, it is not guaranteed that the pattern will always give you positive results. The correct choice of pattern solution is very important. When it comes to Software Engineering Field, Patterns are present at various levels of abstraction in the software code. The term “Design Pattern” was introduced by the GoF ( Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides). GoF introduced 23 commonly occurring design patterns in Object-Oriented Software development. Design Pattern is a pattern of relationship among the classes of OOP based system. We are not going to discuss these design patterns. We will keep our focus on the Django Design Patterns.
If you are not aware of Django then please visit the following link:https://www.djangoproject.com. It is a python based web application development framework, which is getting high attention at the present time. It will be very useful for developers to have this skill in their bag. Unlike traditional Design Patterns, Django Design Patterns (DDP) are not strictly occurring patterns among the classes. DDPs are actually best practices followed by the Django developers. Before Diving into Pattens we need some basic knowledge about the various components of a Django Application.
A basic Django App four essential components.
- Models (models.py): POPOs (plain old python objects) classes to communicate with Database and preserve the data in OOP manner.
- Forms (forms.py): To collect the data from the users.
- Views (views.py): Central controller to handle the user’s request and communicate to model objects. IT is like “servlets” of JavaEE.
- Templates(templates folder): Display response to the users in a generalized structure with customized information.
In addition to the above components, there are some other files and folders which are not relevant to this discussion. DDPs are mainly located in the above four components. 15 DDPs are categorized as follows:
- Model DDP: DDPs under Model are subdivided into Structural and Retrieval Patterns.
1.1 Structural: These Patterns deal with the structure and the Organization of our model classes. In general, we define all the classes in single models.py file.
1.1.1 Normalized Models: Django follows the concept of ORM (Object Relational Mapping). We first define our model classes which automatically generates the database tables. If you have gone through the course of DataBase Management System then it is a trivial DDP to discuss with you. In simple terms, We create our classes and attributes in such a manner which leads to a less redundant, highly consistent and durable database. For example, I will not store the user’s address in a single string. I will provide him/her selection list for the country, State, City, and a single string input for street information, which will keep my data consistent and less redundant.
1.1.2 Model Mixin: Many times we encounter the problem of commonly occurring attributes in different classes. Python comes with the flexibility of Multiple Inheritance. Instead of repeating the same set of attributes across the numbers of model classes, create one parent class and keep these common attributes in the parent class. All the required classes will inherit the parent class. But the problem is that we don’t want to create a table for this parent class in our database. “Abstract Inheritance” is the solution for this. Mark the parent class as “abstract” in the meta inner class of Parent class and the rest of the work will be done by Django.
1.1.3 User Profile: A single web application can have multiple types of users with different level of access permissions. Each user type will have its dedicated set of pages. How we can manage it at the model level!!. An additional class, UserProfile with one-to-one Mapping to User class can resolve the issue. Whenever a user logs in into the application, based on its profile value we can allow or deny the user for accessing the data.
1.1.4 Service Object: This DDP is related to the problem of Fat Models. When A huge amount of code which is not directly related to any of the Model class (just utility code), could be dumped into any of the model class. Which unnecessary increases the size of our model. Extract all these utility code blocks and put into a common Utility class in the form of methods. Mark all the methods “static” as these methods are not related to any of the model class. For better understanding, create separate file utils.py/ services.py to store the Utility class. Example: Generation of JSON/XML based response, Generation of PDF file for download, Communication with external systems.
So, This is it for this post. We will continue our discussion in the next post. We have just discussed the general notion of some DDPs. Please go through the above-mentioned book for details and code-based examples. Thanks for reading the post. Visit the following link for working examples: https://github.com/DjangoPatternsBook/superbook.
[Code Author: Arun Ravindran (GitHub id: arocks)]
Click here for Part2.
