Well, I was just using the MailService as an example of an expensive to create service, as it was mentioned before, not as a concrete case.
On 22 mar, 10:35, Fabien Potencier <fabien.potenc...@symfony- project.com> wrote: > On 3/22/10 10:24 AM, alberto wrote: > > > 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. > > But the mailer is already a proxy in the sense that the connection to > the SMTP server is only done when you send an email. > > Fabien > > > > > > > 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.
