What I was proposing is injecting a proxy object instead of the service itself, and only instantiate the real object (e.g. the MailService) when a method is called on it (e.g send(mail)). I am not sure why you say it needs to be created right away.
On 22 mar, 08:55, Fabien Potencier <fabien.potenc...@symfony- project.com> wrote: > On 3/22/10 1:28 AM, alberto wrote: > > > 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. > > The problem is not to set a couple of vars, but the cost associated with > creating the objects themselves. > > > > > 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). > > The DIC already lazy-load the services. They are only created on demand > when you need them. But if a method needs a service as an argument, of > course we need to create it right away. > > Fabien > > > > > 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.
