Django Best Practices— Project Layout

• Default Django project layout — it get created when run following command on terminal

$ django-admin.py startapp my_app

Note — There are a number of problem with django’s default project layout. Its useful for tutorial but not useful in Real project.

Fundamentals of django App design

Django ( Project )— web framework

Django App — are small libraries designed to represent a single aspact of a project.

Dajngo project is made up of many django app.

INSTALLED-APPS — List of app/libraries

The golden rule of django app design

• “the art of creating and maintaining a good django app is that it should follow the truncated Unix philosophy according to Douglas Mcllroy: Write programs that do one thing and do it well ”.
• Each app should be tightly focussed on its task.
• Need to divide App — When app is too big.

Name your django App

• Possibly, keep to single word name like (flavours, animal)
• The app’s name should be a plural version of the app’s main model. But there are same exception.
• Don’t just consider the app’s main model. You should also consider how you want your URLs to appear when choosing a name.

https://www.example.com/weblog/

Then consider naming your app weblog rather than “blog”, ‘post’ even if main model is “blog”. This style make easier for us to see which app corresponds with which part of site.

Doubts, Keep Apps small

• Design an app is as art. Sometimes you have to rewrite or break them up. That’s okay.
• Try to keep it small

Modules Belongs in an App

• Common App Modules — python package
• Uncommon App Modules — following are

1. behaviors.py — An option for locating model mixin.
2. constants.py — A good name for placement of app-level settings. If there are enough of them involved in an app, breaking them out into their own module, this can add clarity to a project.
3. decorators.py — Where to locate our decorators.
4. db/ — Used in many projects for any custom model fields or components.
5. fields.py — is commonly used for form fields, but is sometimes used for model fields when there is not enough field code to justify creating a db/ package.
6. factories.py — where to place test data factories
7. helpers.py — also as utils.py. Here we put code extracted from view and models to make them lighter. code would be reusable.
8. managers.py — When models.py grows too large, to move any custom model managers to this modules.
9. signals.py — custom signals
10. utils.py — helpers.py
11. viewmixins.py — keeping any view mixin to this