Hey Tomas,
> Are there any sources on why we opted for ServiceLocator rather than
> DIC? I looked at
>
http://framework.zend.com/wiki/display/ZFDEV2/RFC+-+ServiceLocator, but
> that does not answer the core question. I assume the problem was that
You can read the meeting notes here:
http://framework.zend.com/wiki/display/ZFDEV2/2012-04-25+Meeting+Log#2012-04-25MeetingLog-ServiceManagerProposal%28WasInstanceManager%2CWasServiceLocator%29Outside of the issues presented in the Service Manager, here are some
more issues not explicitly described:
* DiC's require that you meta-program. You configure it, the
container does all of the new calls. This means that instead of
programming, you're metaprogramming.
* The above is not an issue in and of itself, it becomes an issue
when developers want to use the DiC for every object in their
application, whether or not it truly is a service that should be managed
by the DiC. When this becomes the case (and it was the case), your
configuration for the DiC grew to massive proportions (I'm sure there
are still some apps out there where this is still in their log.) In any
given request, if you stopped inside an application controller's action,
there were around 170-ish objects currently in PHP's memory, most of
these were created by Zend\Di (somewhere between 90 and 120 if I recall
correctly).
(more below)
> DIC configuration cannot be cached (as in op-code cache). But that can
> be solved pretty easily with DIC generating, right? What happens now is
* Without a ton more work to Zend\Di, you can't generate a dependency
full / configuration free compiled version of a DiC for usage in PHP.
That was the problem we were facing, and even then, you would have
needed to run this compiler anytime you made a change in development to
your service configuration. I'd argue that having to compile stuff is
not the PHP way.
> (as I see it) that generating of the container is burdened on the
> developer - he have to create anonymous functions as small factories to
> create the dependencies. As in
>
http://framework.zend.com/manual/2.0/en/modules/zend.service-manager.quick-start.html#examples> line 25. Or create FactoryClasses.
>
> The purpose of using DI was to be verbose about class'es dependencies.
> But now we hide it behind ServiceLocator. Why is that?
ServiceManager allows you to expression the creation of services in the
form of Factories or closures (I prefer the latter, it's similar to what
you'd see in Pimple, for example, which is not a DiC, but a Service
Locator).
By my definition, the ServiceManager fails to be a true DiC since it
does not do either of the following:
* auto-instantiation
* auto-wiring
It does require you to create your factories and/or closures, give them
a name, then use them to resolve any service dependencies you have.
ServiceManager, even though it can proxy to Zend\Di for abstract
factories, is still (IMO), a far simpler to grasp component for the
purpose of instance/service management.
By other's definitions, you could still call the ServiceManager a DiC,
after all Fabien calls Pimple a Dependency Injection Container.
If you never inject it into a consumer, it never becomes a "Service
Locator"; it's just a container that produces instances by name.
So, there you have it, hope that helps ... I'm sure there are plenty
more thoughts and reasons on the switch :)
-ralph
Locked
