3 ms·
It sounds to me like you could use model managers and just call it a service layer. >in practice, changing your data model in some way is actually pretty commo
by hitchstory 3y ago
It sounds to me like you could use model managers and just call it a service layer.
>in practice, changing your data model in some way is actually pretty common
I find this to be very true on some projects and very not true on others.
Where it is true the abstraction would be beneficial but if you assume all projects have this problem and therefore jam the abstraction into a project that doesn't have it you're just creating overhead.
- rpep 3y agoModelManagers are directly coupled to one model though. You mix concerns if you need to reference other models in them. For e.g. say you have a User model and a corresponding “Profile” model. If you need to create the profile object when the user is created, it doesn’t really feel appropriate to put that in a UserModelManager directly coupled to the User object. This is the example given from the Hacksoft Django style guide to advocate creating a service layer. In terms of the abstraction, I totally agree and tend to be pretty pragmatic about this sort of thing.
- dec0dedab0de 3y agoi don't see anything wrong with it if there are relationships between Profile and User, but if you feel bad about abusing a manager, you could just do a classmethod, or a separate function all together.