Basic principles of Django App Design

Time:2020-4-21

basic principle

Every app should do just one thing. Its function should be described clearly in a simple statement. If more than one “and” is used in the description process, it may mean that the app is a little big and needs to be split.

James Bennett:
The art of creating and maintaining a good Django app is that it should follow the truncated Unix philosophy according to Douglas McIlroy: ‘Write programs that do one thing and do it well.’

How to name Django app

  1. Try to use one word, such asanimals, blog, dreamspolls。 Simple and semantic project names are easier to maintain.
  2. If appropriate, you can refer to the name of the master data model in the app, which is plural.
  3. When naming, consider the form of URL. For example, if the URL of a blog can be http://www.example.com/weblog/, consider naming the app weblog instead of blog or posts.
  4. Use small letters for naming. Do not use numbers or other characters. Use underscores if necessary_But try to avoid using.

When hesitant, choose a small app solution

The separation and design of APP functions is an art, not a technology. Therefore, it may be necessary to split and reorganize in the future.

Try to make one app small enough, and multiple small apps are easier to maintain than one large app.

What are the modules in an app?

Common modules:

These modules can be seen in 99% of Django apps:

# Common modules
scoops/
    __init__.py
    admin.py
    forms.py
    management/
    migrations/
    models.py
    templatetags/
    tests/
    urls.py
    views.py

Less common modules

# uncommon modules
scoops/
    behaviors.py
    constants.py
    context_processors.py
    decorators.py
    db/
    exceptions
    fields.py
    factories.py
    helpers.py
    managers.py
    middleware.py
    signals.py
    utils.py
    viewmixins.py

The function description of each module is as follows:

Modular Function description
constants.py App level settings. If there are too many settings in app, they should be put in this file independently
decorators.py Decorator for app
Db / package Customized data model items and other database related components
fields.py Place customized data model items. If there are not many database related components, you can only put them in this file without creating a DB package
factories.py Factory function to generate test data
helpers.py Some auxiliary functions extracted from views.py and models.py
utils.py Same as helpers.py
managers.py When the model.py is large, you can extract the customized model managers
signals.py Customized signal
viewmixins.py Mixins extracted from views.py

Reference: two scoops of Django: Best Practices for Django 1.8