We've got a bunch of models, so we (wisely, I think) break them up into submodules in the platform app's models namespace so that they're easy to find.
In my work on the 3.0 REST API, I'm mirroring this layout when defining the serializers, because we're pretty likely to have at least one serializer for every model, and we're also pretty likely to have a few custom fields on those serializers, as well. This is working well, but seems to me to be a bit of a rabbit hole when other API components are taken into effect, particularly ViewSets. Each API endpoint is represented by a ViewSet, and each ViewSet is related to a Django Model and that Model's Serializer. While we won't necessarily have a ViewSet for every Model, we're pretty likely to have a whole lot of them, so it seems like they should be similarly organized. So, my question is: Should we generally break up Model-related objects the same way we've broken up our models (like ViewSets, Serializers, etc)? Pros: All objects (Models, Serializers, ViewSets, etc) are in a single module's namespace. This makes them easy to discover when initializing apps, and also raises errors related to circular import issues very quickly. Discoverability, in particular, is Pretty Important™. Cons: /me writes pulp.app.models.foo.Foo /me imports Foo into pulp.app.models /me writes pulp.app.serializers.foo.FooSerializer /me imports FooSerializer into pulp.app.serializers /me writes pulp.app.viewsets.foo.FooViewSet /me imports FooViewSet into pulp.app.viewsets /me is le tired, but gets over it because at least things are consistent? I think it makes sense to keep things broken up just like the models, but I'm nervous about how deep this rabbit hole might be, and if at some point it just becomes a ridiculous maintenance headache. :)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
