Quantcast

Service Locator

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Service Locator

Tomáš Fejfar
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 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 (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?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Service Locator

ralphschindler
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%29

Outside 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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Service Locator

weierophinney
Administrator
-- Ralph Schindler <[hidden email]> wrote
(on Tuesday, 02 October 2012, 01:07 PM -0500):
> By other's definitions, you could still call the ServiceManager a
> DiC, after all Fabien calls Pimple a Dependency Injection Container.

Actually, I'd argue it's more properly termed an Inversion of Control
(IoC) container. Zend\Di is, as well. The argument is that the
dependencies are being injected for you when you retrieve an instance.

> If you never inject it into a consumer, it never becomes a "Service
> Locator"; it's just a container that produces instances by name.

To make this easier to understand (I misread at first due to the
negative verbiage):

    If you inject it into a consumer, it becomes a "Service Locator". If
    not, then it is an Inversion of Control container, producing
    instances by name.

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
Loading...