HackSoftware/Django-Styleguide
1
1
Fork 0
mirror of https://github.com/HackSoftware/Django-Styleguide.git synced 2025-03-12 23:05:48 +03:00
Code Issues Packages Projects Releases Wiki Activity

Add emojis

Browse Source
This commit is contained in:
Radoslav Georgiev 2022-01-21 14:08:14 +02:00
parent 0983eb9eae
commit 702ca6d287
No known key found for this signature in database
GPG Key ID: 0B7753A4DFCE646D
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
README.md
View File

@ -105,7 +105,7 @@ The general idea is to "separate concerns" so those concerns can be maintainable
## Why not?
> Why not put your business logic in APIs / Views / Serializers / Forms?
> 🤔 Why not put your business logic in APIs / Views / Serializers / Forms?
Relying on generic APIs / Views, with the combination of serializers & forms does 2 major things:
@ -125,7 +125,7 @@ This styleguide aims to:
---
> Why not put your business logic in custom managers and/or querysets?
> 🤔 Why not put your business logic in custom managers and/or querysets?
This is actually a good idea & you might introduce custom managers & querysets, that can expose better API, tailored to your domain.
@ -146,7 +146,7 @@ With all that in mind, custom managers & querysets are very powerful tool and sh
---
> Why not put your business logic in signals?
> 🤔 Why not put your business logic in signals?
From all of the available options, perhaps, this one will lead you to a very bad place very quickly: