dip VS Swinject

And then also add dip to get rid of these lengthy docker compose run prefixes from the every command typed in your console.

So, I went the old-fashioned way and added Dip to the mix. Now I can run all the familiar commands (bundle, rake, etc.) from my host system (with a dip prefix) without thinking about all the docker-compose --rm --it bla-bla. Moreover, I can cd into a subfolder (say, actioncable), and execute commands from there just like on a host machine:

And in this case this utility can safe us. DIP has two possible modes:

I'd be sure to also check out (if you haven't already) https://evilmartians.com/chronicles/ruby-on-whales-docker-for-ruby-rails-development, it might have some solutions to your problems, like using a cached Docker volume to mount your application's directory. Evil Martians also developed DIP to help make the Docker workflow more approachable.

DI is a concept which makes a class independent of its dependency management. It achieves that by decoupling the usage of an object from its creation. This helps you to follow SOLID’s dependency inversion and single responsibility principles. To achieve this in Swift one of the most appreciated library is Swinject. This library not only provides DI but also have many other features like:-

Swinject - Dependency injection framework for Swift. Language: Swift.

We use Swinject which is probably quite similar https://github.com/Swinject/Swinject

So, how do we fix this? There is a cleaner solution. By using a dependency injection framework, such as Swinject we can create a base module that we might call the DI module.