❔ Services becoming dependent on each-other, possible solution, opinions?
I'm pretty sure that asking for opinions is fine, at least I hope. (I think that software engineering isn't exact science, everything depends and has many approaches)
As I spoke to one kind user from here the other day, we talked about how services become dependent on each other as projects grow, which leads to many problem such as circular dependencies and another one which is fat constructor (large amounts of injections => many parameters => ugly code?).
Well, I tried solving this to come prepared and I started actually stumbling upon these problems in my project. (Which is just a simple Web Api I'm building for my Github profile). After reading Martin Fowler's book "Patterns of Enterprise Application Architecture", "Design Patterns Elements of Reusable Object-Oriented", Refactoring Guru and many SO issues, didn't come with many solutions apart from dumping services and migrate to CQRS(which the same kind senior talked to me about), Service Locator pattern, Property injection, and some more.
All seemed a bit weird to me, I can't explain, each had their drawbacks which I wasn't fancy about dealing with (except for CQRS which I wanted to use in another project and keep this one with services), so I came up with what you're seeing in this picture. I'm not sure if what I've done is a mix of some, maybe it's improper way to implement Service Locator, so I named it differently to not look like an idiot.
I'll try to explain what I'm doing:
1. A Gatherer would centralize calls between services by supplying the services.
2. Each controller is injected with the gatherer, then keeps only the relevant service as a prop.
3. When a Gatherer is instantiated, it is injected with all of the services (I don't like it but there had to be compromises).
4. To minimize code repetition I created
That's it, would appreciate other solutions and opinions.
As I spoke to one kind user from here the other day, we talked about how services become dependent on each other as projects grow, which leads to many problem such as circular dependencies and another one which is fat constructor (large amounts of injections => many parameters => ugly code?).
Well, I tried solving this to come prepared and I started actually stumbling upon these problems in my project. (Which is just a simple Web Api I'm building for my Github profile). After reading Martin Fowler's book "Patterns of Enterprise Application Architecture", "Design Patterns Elements of Reusable Object-Oriented", Refactoring Guru and many SO issues, didn't come with many solutions apart from dumping services and migrate to CQRS(which the same kind senior talked to me about), Service Locator pattern, Property injection, and some more.
All seemed a bit weird to me, I can't explain, each had their drawbacks which I wasn't fancy about dealing with (except for CQRS which I wanted to use in another project and keep this one with services), so I came up with what you're seeing in this picture. I'm not sure if what I've done is a mix of some, maybe it's improper way to implement Service Locator, so I named it differently to not look like an idiot.
I'll try to explain what I'm doing:
1. A Gatherer would centralize calls between services by supplying the services.
2. Each controller is injected with the gatherer, then keeps only the relevant service as a prop.
3. When a Gatherer is instantiated, it is injected with all of the services (I don't like it but there had to be compromises).
4. To minimize code repetition I created
IAppServiceAppServiceAddGatherer(IServiceGatherer)That's it, would appreciate other solutions and opinions.
