mirror of
https://github.com/HackSoftware/Django-Styleguide.git
synced 2025-02-06 22:50:53 +03:00
Add section for handling updates via a service
This commit is contained in:
parent
f4d1a33c69
commit
cbd995e730
28
README.md
28
README.md
|
@ -424,6 +424,34 @@ As you can see, this service calls 2 other services - `profile_create` and `conf
|
|||
|
||||
In this example, everything related to the user creation is in one place and can be traced.
|
||||
|
||||
### Handling updates
|
||||
|
||||
As for updating, we have a generic update service that we use inside of the actual update services. Here's what a sample `user_update` service would look like:
|
||||
|
||||
```python
|
||||
def user_update(*, user: User, data) -> User:
|
||||
non_side_effect_fields = ['first_name', 'last_name']
|
||||
|
||||
user, has_updated = model_update(
|
||||
instance=user,
|
||||
fields=non_side_effect_fields,
|
||||
data=data
|
||||
)
|
||||
|
||||
# Side-effect fields update here (e.g. username is generated based on first & last name)
|
||||
|
||||
# ... some additional tasks with the user ...
|
||||
|
||||
return user
|
||||
```
|
||||
|
||||
* We're calling the generic `model_update` service for the fields that have no side-effects related to them (meaning that they're just set to the value that we provide).
|
||||
* This pattern allows us to extract the repetitive field setting in a generic service and perform only the specific tasks inside of the update service (side-effects).
|
||||
|
||||
The generic `model_update` implementation is in the [`Cookbook` section](#generic-update-service).
|
||||
|
||||
The full implementation of this approach can be seen [in our example project](https://github.com/HackSoftware/Django-Styleguide-Example/blob/master/styleguide_example/users/services.py).
|
||||
|
||||
### Naming convention
|
||||
|
||||
Naming convention depends on your taste. It pays off to have something consistent throughout a project.
|
||||
|
|
Loading…
Reference in New Issue
Block a user