ZfcUser\Service\User dependency injection pattern explanation

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

ZfcUser\Service\User dependency injection pattern explanation

Julian Vidal
After attending ZendCon 2012 I saw how a lot of classes in ZF2 that
implemented DI and had their dependencies passed to them through the
constructor. I understand that ZF2 has a Service Manager that helps
with this. I'm trying to learn how to implement this and learn its
best practices.

And then... I loaded up the ZfcUser module and saw that the User
Service (https://github.com/ZF-Commons/ZfcUser/blob/master/src/ZfcUser/Service/User.php)
was not quite following this pattern, in fact it was hiding it's
dependencies behind a bunch of lazy loading getters. Now, this module
was initially written by Evan Coury so I think it's safe to say that
this module is well written or at least follows the suggested zf2 best
practices.

My question is, why is this class hiding its dependencies behind
getters and actually getting them from the Service Manager instead of
defining them explicitly in the constructor?

Isn't this in fact going against the DI principle of making
dependencies explicit? Note that I might have misunderstood this
completely so I'm trying to grasp the gist of it!

Thanks!
Julian

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: ZfcUser\Service\User dependency injection pattern explanation

Artur Bodera
On Tue, Nov 13, 2012 at 8:50 PM, Julian Vidal <[hidden email]>wrote:

> Isn't this in fact going against the DI principle of making
> dependencies explicit? Note that I might have misunderstood this
> completely so I'm trying to grasp the gist of it!
>

It's not against it.
It's still an "Inversion of Control" way of doing things, which is a good
thing.

ZF2 DI has been in active development in late 2011 and has gained a lot of
traction among contributors. At some point though, the performance and
config files' complexity became an issue. That's why ServiceManager idea
has been brought up.

Up until beta1 (AFAIR) nearly everything was defined in DI and config files
were humongous. Applications were slow, memory usage was through the roof,
the complexity actually rose as compared to ZF1 Application_Service or
similar. There were ideas on how to further optimise DI, but a group of
contributors came up with another idea: SM.

ServiceManager allows for more explicit way of building up services. For
example, instead of an array of arrays with 20 keys (which is required for
DI to be able to handle dependencies correctly and construct objects), you
can just use a _single_ factory function/class with a few "new This", "new
That" and "return $service" at the end.

There's no strict policy or recommendation against SM nor DI. Both are OK,
both have strengths and weaknesses. It's your choice which you'll use. Both
are recognised by Zend\Mvc and will be read from you app config.

As for modules - each module's author decides on which method to use. Again
- both are valid ways of handling dependencies and automatically
constructing instances. Evan chose SM factories in this example.


A.

--
      __
     /.)\   +48 695 600 936
     \(./   [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: ZfcUser\Service\User dependency injection pattern explanation

Julian Vidal
Artur,

Thank you for your input. It's been very informative!

Julian.

> It's not against it.
> It's still an "Inversion of Control" way of doing things, which is a good
> thing.
>
> ZF2 DI has been in active development in late 2011 and has gained a lot of
> traction among contributors. At some point though, the performance and
> config files' complexity became an issue. That's why ServiceManager idea has
> been brought up.
>
> Up until beta1 (AFAIR) nearly everything was defined in DI and config files
> were humongous. Applications were slow, memory usage was through the roof,
> the complexity actually rose as compared to ZF1 Application_Service or
> similar. There were ideas on how to further optimise DI, but a group of
> contributors came up with another idea: SM.
>
> ServiceManager allows for more explicit way of building up services. For
> example, instead of an array of arrays with 20 keys (which is required for
> DI to be able to handle dependencies correctly and construct objects), you
> can just use a _single_ factory function/class with a few "new This", "new
> That" and "return $service" at the end.
>
> There's no strict policy or recommendation against SM nor DI. Both are OK,
> both have strengths and weaknesses. It's your choice which you'll use. Both
> are recognised by Zend\Mvc and will be read from you app config.
>
> As for modules - each module's author decides on which method to use. Again
> - both are valid ways of handling dependencies and automatically
> constructing instances. Evan chose SM factories in this example.

--
List: [hidden email]
Info: http://framework.zend.com/archives
Unsubscribe: [hidden email]