Canonical way of using multiple repositories in a service

[suspiciousRaccoon]

hi! ฅ^•ﻌ•^ฅ

The service docs mention that services can handle operations involving multiple repositories, however, I wasn't able to find an example in the docs or the litestar-fullstack application where this is done, and the service code doesn't really look like it was made with multiple repos in mind.

What is the canonical way of having a service with multiple repositories? Or is this something that isn't supported and should be done elsewhere? Like maybe wrapping services inside a normal class?

[shetty13]

Have you found a decent workaround? I think there is a strong use case for this, a service should not be restricted to a single repository since it serves as the business logic layer which in most cases will span across multiple repositories.

[suspiciousRaccoon]

Unfortunately I haven't.

The options I came up with boil down to this:

1. Single repo per service and orchestrate operations in the controller. This is what the litestar-fullstack example does. with the downside of business logic leaking into the controller.
2. Extra parent service class that uses multiple services. I dislike this because then the new service class would need to handle the DI of the services and the UOW and all the extra options current services use, when the services already do them. Then there could also be problems of circular dependencies and spaghetti code. I don't think a service should depend on others, or maybe sparingly. I think multiple repos in a single service are fine.
3. Ditch the service class and only use repos. I dislike this for the same reason as 2. We would need to create a whole service class from the ground up and reimplement the busywork current services do, or live without it.

There is a secret 4th option in subclassing and implementing multi-repo support with the current service class, but since the current implementation is too coupled on the single repo paradigm I don't think this would be a good idea.

For now the best option is probably 1, It's what's used in the example app and the most simple.

However Advanced alchemy 2 is coming soon and this would be a good time to add this feature. I'll add it to the open issue.

[shetty13]

Thanks for the breakdown, these are good options.
I've actually gone down the route of injecting another repository within my service (where I require it), it works well enough for my use case i.e. orchestrating multiple db operations across different models within a single transaction.