I've been using this service pattern although not in Django - in Flask. The main benefit is a lot of code doesn't need to depend on a request context. We can happily have backend scripts calling services and we intentionally don't let the request context bleed into that layer.
Also, may just be me, but I've mostly seen just bad Django apps - God object patterns galore, the schema/orm/business logic all being very tightly coupled and essentially nothing is able to be refactored because of this. They often have to be simply thrown away and you start over.
But, I think having an explicit service interface solves a lot of these problems - as long as you maintain the interface and pass back the same type of object, you're free to talk to whatever backing store you like. And you get a lot less issues with circular imports and whatnot in my experience. ymmv
I think services definitely make sense in flask because flask has no built in ORM, you'll end up using sqlalchemy. Even the author concedes that in some non-django applications it may make sense
> And if, after reading this, you still are convinced that a service-layer approach with business logic separate from the data models is the right thing for you, then go for it, but I’ll urge you one last time to at least strongly consider not doing it with Django, and instead building on top of a component stack that uses a Data Mapper ORM (in the Python world, SQLAlchemy is far and away the best choice) that natively incorporates that type of separation. In the long term, I think that’s going to be a much happier and more productive path than trying to fit the square peg of a service layer into the round hole of Django’s Active Record approach.
I've been using this service pattern although not in Django - in Flask. The main benefit is a lot of code doesn't need to depend on a request context. We can happily have backend scripts calling services and we intentionally don't let the request context bleed into that layer.
Also, may just be me, but I've mostly seen just bad Django apps - God object patterns galore, the schema/orm/business logic all being very tightly coupled and essentially nothing is able to be refactored because of this. They often have to be simply thrown away and you start over.
But, I think having an explicit service interface solves a lot of these problems - as long as you maintain the interface and pass back the same type of object, you're free to talk to whatever backing store you like. And you get a lot less issues with circular imports and whatnot in my experience. ymmv
I think services definitely make sense in flask because flask has no built in ORM, you'll end up using sqlalchemy. Even the author concedes that in some non-django applications it may make sense
> And if, after reading this, you still are convinced that a service-layer approach with business logic separate from the data models is the right thing for you, then go for it, but I’ll urge you one last time to at least strongly consider not doing it with Django, and instead building on top of a component stack that uses a Data Mapper ORM (in the Python world, SQLAlchemy is far and away the best choice) that natively incorporates that type of separation. In the long term, I think that’s going to be a much happier and more productive path than trying to fit the square peg of a service layer into the round hole of Django’s Active Record approach.
Yeah, I'd think it's probably a really bad fit for Django. I'm doing it with SQL + psycopg2, so tired of fighting the ORM.