3 ms·
I agree with you. It is a bit weird that a serializer can interact with the database but what it basically does: hides the database interaction.
by norbert_mate 12y ago
I agree with you. It is a bit weird that a serializer can interact with the database but what it basically does: hides the database interaction.
- skatenerd 12y agoout of curiosity, how often do you find yourself reading the DRF source code to figure out whats happening?
- norbert_mate 12y ago"The best documentation is the source code" :-) . I use to read it but sometimes is really hard to understand what's going on. As you said the serializer does a lot of thing.
- tomchristie 12y agoThe model / model manager layer is the right place at which to design your state changing API. REST framework absolutely you to work with the grain there. Some good practice I'd recommend... * Write the `create()` and/or `update()` methods explicitly on the serializer class. * Push logic into the model and model manager where possible and only have the serializer `.save()` as a thin layer on top of that. That way a serializer class still has all the behavior it needs to map both ways between persisted objects and their corresponding native python representations, but you still have a well separated model API.
- skatenerd 12y agoInteresting. In practice, I have started following a pattern where I have two Serializer classes - a "serializer" and a "deserializer". The "deserializer"'s job is to perform validation and type coercion of incoming requests. It returns a "native" dictionary, which the application code then saves to ORM. The "serializer" is basically a presentation layer. It calls out to other nested serializers [this is awesome!], and it throws in convenience-fields that make the API response easier to consume. This pattern makes it a little bit less "magical", and it's easier to distinguish between the API's "incoming" behavior and its "outgoing" behavior.