HackSoftware/Django-Styleguide
1
1
Fork 0
mirror of https://github.com/HackSoftware/Django-Styleguide.git synced 2024-11-25 19:13:45 +03:00
Code Issues Packages Projects Releases Wiki Activity

Improve on the initial sections

Browse Source
This commit is contained in:
Radoslav Georgiev 2021-09-16 15:36:31 +03:00
parent c63b60ff7d
commit 81e8cd0519
No known key found for this signature in database
GPG Key ID: 0B7753A4DFCE646D
1 changed files with 9 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
README.md
View File

@ -64,8 +64,8 @@ If you want to check an existing project showing most of the styleguide, [check
* Model properties (with some exceptions). * Model properties (with some exceptions).
* Model `clean` method for additional validations (with some exceptions). * Model `clean` method for additional validations (with some exceptions).
* Services - functions, that take care of writing to the database. * Services - functions, that mostly take care of writing things to the database.
* Selectors - functions, that take care of fetching from the database. * Selectors - functions, that mostly take care of fetching things from the database.
**In Django, business logic should not live in:** **In Django, business logic should not live in:**
@ -76,14 +76,18 @@ If you want to check an existing project showing most of the styleguide, [check
**Model properties vs selectors:** **Model properties vs selectors:**
* If the model property spans multiple relations, it should better be a selector. * If the property spans multiple relations, it should better be a selector.
* If a model property, added to some list API, will cause `N + 1` problem that cannot be easily solved with `select_related`, it should better be a selector. * If the property is non-trivial & can easily cause `N + 1` queries problem, when serialized, it should better be a selector.
## Cookie Cutter ## Cookie Cutter
We recommend starting every new project with some kind of cookiecutter. Having the proper structure from the start pays off. We recommend starting every new project with some kind of cookiecutter. Having the proper structure from the start pays off.
For example, you can use [`cookiecutter-django`](https://github.com/pydanny/cookiecutter-django) Few examples:
* You can use the [`Styleguide-Example`](https://github.com/HackSoftware/Styleguide-Example) project as a starting point.
* You can also use [`cookiecutter-django`](https://github.com/pydanny/cookiecutter-django) since it has a ton of good stuff inside.
* Or you can create something that works for your case & turn it into a [cookiecutter](https://cookiecutter.readthedocs.io/en/latest/) project.
## Models ## Models