Hi guys. I would like to give my opinion on the subject. You could
basically sum it up essentially as "please don't reinvent the wheel".

Favor constructor injection for all required services. With the use of
type hints, it makes dependencies very clear and in a clean way. It
also avoids the problem of naming collisions. And I don't think having
to set a couple of vars per controller is really an issue.

For optional dependencies you can use setter injection (or private
properties if you will). You probably want annotations to avoid the
problem of knowing wheter something should be injected.

Please don't inject the container as a service locator. It just hides
dependencies and make testing a little harder.

Regarding the problem of having very disparate services not needed for
every action, I think, as someone else already said, this is a smell
of your controller trying to do too many things.

If you really need an expensive-to-create service which is only needed
for not all of your actions, and it really belongs there, (like the
mailing service you are discussing) then I think it should be lazy
loaded. If you want to relieve the users from having to take care of
that, maybe something at the container level could be implemented to
be able to indicate that when wiring the service. I think it could be
done via dynamic proxies (in the same way Doctrine does, if I am not
mistaken).

alberto

On 21 mar, 18:10, Jordi Boggiano <[email protected]> wrote:
> On Sun, Mar 21, 2010 at 6:06 PM, Richtermeister <[email protected]> wrote:
> > I keep seeing the example of the mailer as a dependency of an action,
> > but in reality, aren't dependencies often conditional?
> > For example, sending a mail often depends on whether, say, a form
> > validates. By passing the mailer into the constructor or the method
> > directly, we would "always" instantiate it, even though it's only
> > "sometimes" needed.
> > Having read about the DI container, I was under the impression that
> > it's lazy loading abilities were supposed to fix just that problem,
> > that the mailer is only instantiated when I really (!) need it, not
> > "potentially" need it.
>
> This is only true if you pass the entire container, then when you do
> $container->mailer, it instantiates it. If you pass it as a parameter
> directly, no matter how, it is indeed instantiated always.
>
> As I previously said, in most cases, the code sending a mail isn't
> going to be executed that much that it actually matters, but in some
> cases it might. In those cases though, you could always ask for the
> $container service itself as a parameter, and fetch the mailer from it
> only when really needed.
>
> Cheers,
> Jordi

-- 
If you want to report a vulnerability issue on symfony, please send it to 
security at symfony-project.com

You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en

To unsubscribe from this group, send email to 
symfony-devs+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Reply via email to