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.
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
- Try to use one word, such asanimals, blog, dreams， polls。 Simple and semantic project names are easier to maintain.
- If appropriate, you can refer to the name of the master data model in the app, which is plural.
- 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.
- 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?
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:
|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|
|viewmixins.py||Mixins extracted from views.py|
Reference: two scoops of Django: Best Practices for Django 1.8