Service with multiple repositories and other dependencies

perhaps you are violating the single responsibility pattern? in other words your service might have too many responsibilities.

If you need multiple repositories is very likely your service class is mixing concerns, and probably can be broken down in multiple classes with a single responsibility.

@keevitaja @Flatline, I think this is it, but I'm having a bad time refactoring it.

For example:

I have a ProposalService that have a method called 'updateCosts'. This method needs to change some attributes in other 4 tables/repositories, so I have injected them in the construct. This class still have other methods, like 'calculateMargin' that have different dependencies.

I'm really having a bad time trying to figure this out and I think to study more before diving into it, can you guys recommend some books or articles?

Thanks!!

I think that instead of using service classes you should think in commands, so you could have a class named UpdateProposalCosts and do just that, then maybe you can use domain events to trigger other updates or even trigger other commands.

I feel that your problem goes beyond just how to code it, you need to have clearer business needs and rules. So I'd recommend Domain Driven Design by Eric Evans. There are two great talks by Mathias Verraes on the topic as well, one from PHP UK and the other one from Laracon, I don't have the links right now, sorry.

EDIT: Here are the links to the talks http://verraes.net/2014/09/decoupling-model-framework/ and http://verraes.net/2013/06/unbreakable-domain-models/ these are the ones I've seen.

repository can work with more than one model. i do not know your setup, but maybe you should create ProposalRepository and make things happen in there.

also perhaps you can set up some relationships between the models to ease the process.

I really appreciate your help, @Flatline and @keevitaja. I really think I need to understand the concepts of it before anything else.

Thanks again!

Glad to help! DDD may sound strange at first, because it changes how we think. We're used to "the CRUD way", when we should really focus on communicating the business with the code itself. Another good (and short) article to read: http://verraes.net/2013/04/crud-is-an-anti-pattern/