I have finally got my head around IoC (thanks to Jeffrey and Laracasts :) ) and I'm now looking to apply it to a particular case.
My application has uses two mail providers (e.g. Postmark, Mailgun) so that if the first fails (through time out/unavailability/error) it falls back to the second provider.
Now if I was only using one, I could easily get away with…
public function __construct(MailProviderInterface $mailProvider) {
}
…and have two classes that implement the interface and switch as required. However I need both might need to be loaded in, so is it better to inject a collection of MailProvidersCollection that I can loop through and then use a config file to define each mail provider?
Are there any alternative ways to structure the app that might be better? Has anybody done something similar?
It sounds like it's not 100% related to dependency injection. I feel like you're looking for a chain of responsibility pattern.
Try http://dsheiko.com/subpage/chain-of-responsibility-pattern
That was quick and is what I'm looking for! :) I'll just need to amend it so that it stops running through the chain after the first success, but that's easy to do.
The dependency injection is just to make our unit testing easier (I'm still fairly new to thinking in a unit testable way)... I've realised being able to inject my own class gives me the ability to do things like:
- Mock provider responses (so that I can test fail over to a backup, or admin alerts should all providers "fail")
- Test providers would receive the right info such as email addresses, API keys etc by making sure their expectations are met when called, yet not have to actually send any emails out. (although that's free for us, our text provider isn't and mistakes could be costly!)
That's great though... that's put me on the right track.
Sign in to participate in this thread!
Laravel
Laravel News
Laracasts
Laravel Podcast