Posts tagged with dependency injection
– wendelladriel.com - submitted by Wendell Adriel
Explore Laravel’s Service Container from the ground up: resolution, binding, scopes, contextual dependencies, auto-wiring, and more, and demystify how your app runs.
Read more [wendelladriel.com]
– flareapp.io - submitted by Spatie
Here's why and how we added a mini container in a framework agnostic package.
Read more [flareapp.io]
Join thousands of developers
Every two weeks, I share practical tips, tutorials, and behind-the-scenes insights from maintaining 300+ open source packages.
No spam. Unsubscribe anytime. You can also follow me on X.
These attributes help you inject various pieces of data into your classes
Read more [www.amitmerchant.com]
You should consider using the handle() method for dependency injection in Artisan commands, rather than __construct().
Read more [ides.dev]
Christoph Rumpel wrote a clear post on how you can use Laravel's service container.
The service container is a quite complex topic, and I see many struggling to understand what it does. It was the same for me, and the main reason is that many explanations concentrate on "how" to use the container. With this article, I want to give you my introduction to this topic by focusing on the "why" and "when" the container can help us with our dependencies.
Read more [christoph-rumpel.com]
Matthias Noback wrote down some thoughts on the Laravel container
Laravel's service container looks great. I like the idea that it can figure things out mostly by itself. I like that it's PHP-based, and that its syntax is quite compact. I think that most of the convenience functions (e.g. resolve()) and exotic options (like $this->app->resolving()) should be ignored. The best thing you can do for your application in the long term is to let all your services use dependency injection, and to inject only constructor arguments. This keeps things simple, but also portable to other frameworks with other dependency injection containers, or other architectural styles, when the time is there.
Read more [matthiasnoback.nl]
Matthias Noback makes the case for writting your own service containers.
Dependency injection is very important. Dependency injection containers are too. The trouble is with the tools, that let us define services in a meta-language, and rely on conventions to work well. This extra layer requires the "ambient information" Paul speaks about in his tweet, and easily lets us make mistakes that we wouldn't make if we'd just write out the code for instantiating our services.
Read more [matthiasnoback.nl]
Mattias Noback shares how you can migrate a code base that fetches its dependencies using static method calls to code that uses dependency injection.
I've worked with several code bases that were littered with calls to
Zend_Registry::get(),sfContext::getInstance(), etc. to fetch a dependency when needed. I'm a little afraid to mention façades here, but they also belong in this list. The point of this article is not to bash a certain framework (they are all lovely), but to show how to get rid of these "centralized dependency managers" when you need to.
Read more [matthiasnoback.nl]
In a new post on his blog Matthieu Napoli, creator of PHP-DI, explains how he made v6 much faster.
But the good thing is that, after 6 years of existence, the project has matured and is now quite stable. The original objectives are met, even though there is of course always room for improvements and innovation. There is room to push the container to be better on other levels. And the most obvious one is performances.
PHP-DI 6 will be much, much faster because it is a compiled container.
http://php-di.org/news/21-php-di-6-compiled-container.html
Matthias Noback explains the value of singleton objects: when used properly they can make your code more developer friendly.
I'm not advocating the use of façades and helper functions per se. I assume they may have good use in specific parts of your application (just as the Laravel documentation states, by the way). My point is that, as long as you build into your libraries both options, you can offer a great developer experience, providing an out-of-the-box working solution of a useful service, which can still be used in a project that uses dependency injection everywhere.
At the heart of many modern PHP application there is an IoC Container, short for inversion of control container. When people talk about a "dependency injection container" or a "service container" they mean the same thing. It's purpose is to manage class dependencies. Though the concept is relatively simple, it can come across very confusing if you've never worked with one.
In a new post on his blog Matt Allan builds a simple one from scratch. Check it out if you're struggling with understanding how the IoC container works.
If you are writing modern PHP, you will run across dependency injection a lot. Basically all dependency injection means is that if an object needs something, you pass it in. ... Dependency injection makes your code more flexible and easier to test.
http://mattallan.org/2016/dependency-injection-containers/
EDIT: mattalan.org seems to be down, but you can still view the post in Google's cache.
Jens Segers explains how to use PHP League's shiny new version of Container. The usage of ContainerInterface seems interesting:
League's container now implements the `ContainerInterface`, which is defined by the Container Interoperability group. This is really great as there are a few projects and frameworks which support this interface. For example, the Slim 3 micro framework already allows you to choose your own container flavour, as long as it implements the interface.Read the full article at Jens' blog.
The League's Container seems like a nice alternative to PHP DI that I have been using.
A great talk by John Arstingstall about dependency injection, aka the ioC Container.
http://vimeo.com/88888213