This is a collection of patterns which we have found occurring commonly with Django. All of these either make collaboration easier, coding simpler or code more maintainable. None of them are design patterns in the sense of GoF design patterns. We call them design patterns as none other seem closer or more convenient.
These are guidelines, which need to be overridden (very commonly, in some cases). Use your judgement when using them. As PEP8 says, “Foolish consistency is the hobgoblin of small minds.”
- Django Design Patterns
- Multiple managers
- Custom Manager Methods
- Hierarchical Relationships
- Singleton classes
- Audit Trail and rollback
- Define an __unicode___
- Define a get_absolute_url()
- Use reverse() for calculating get_absolute_url
- Working with denormalised fields
- Abstract custom queries in Manager methods.
- Use a source control system
- Create a requirements.txt
- pin your requirements.txt
- Use virtualenv and pip (sandbox)
- Use pep8.py to check compliance with Python coding guidelines.
- Use one code analyzer for static analysis.
- Use a bug tracking tool.
- Use south for schema migration
- Create various entries in your /etc/hosts mapped to localhost
- Do not commit the generated files
- settings.py and localsettings.py
- Use relative path in settings.py
- Apps should provide default values for settings they are trying to read.
- Use templatetag when the output does not depend on the request
- Import as if your apps are on your project path
- Naming things
- Using pdb remotely
- Do not use primary keys in urls
- Code defensively in middleware and context processors.
- Move long running tasks to a message queue.