tag:blogger.com,1999:blog-1040641208362137940.post1973775578381253213..comments2008-10-02T18:09:44.736+02:00Martin Nilssonhttp://www.blogger.com/profile/03835928417062723879noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-1040641208362137940.post-36914271534799904132008-10-02T18:09:00.000+02:002008-10-02T18:09:00.000+02:00Great! Then we have the same opinion then. Good to point out that both are needed thou for other readers. Thanks Bernardo.Martin Nilssonhttp://www.blogger.com/profile/03835928417062723879noreply@blogger.comtag:blogger.com,1999:blog-1040641208362137940.post-89194892606728717082008-10-02T18:02:00.000+02:002008-10-02T18:02:00.000+02:00Then you missed my point, hehehe.<BR/><BR/>I never said you shouldn't use Component.For. I just said that this approach introduces friction. If that's a tradeoff you are willing to do, by all means do it, but always favor the least-friction approach.<BR/><BR/>Cheers,<BR/>Bernardo HeynemanBernardo Heynemannhttp://www.blogger.com/profile/13719132951779848435noreply@blogger.comtag:blogger.com,1999:blog-1040641208362137940.post-10550623348807286252008-10-02T17:59:00.000+02:002008-10-02T17:59:00.000+02:00Bernardo,<BR/><BR/>There is a need for both of them. I use the automatic registration for my controllers, presenters, services, repositories, etc but I register some components with "Component.For(..)" when I want a specific setup. For example, when I'm running my application in Sweden I want this payment provider and in UK I want another one but I don't want both and have to get them by component key.Martin Nilssonhttp://www.blogger.com/profile/03835928417062723879noreply@blogger.comtag:blogger.com,1999:blog-1040641208362137940.post-75190396178902195752008-10-02T17:06:00.000+02:002008-10-02T17:06:00.000+02:00The second one is not an option to the first one.<BR/><BR/>There's a lot of friction that can be resolved using an IoC Container (I intend to talk about that in my book hehehe).<BR/><BR/>The goal of having an IoC container in place is reaching that "it just works" nirvana when it comes to managing dependencies between components.<BR/><BR/>The first scenario that you showcased really does that, meaning if I add a new service and has some component depend on that service (via constructor or setter injections), it just works.<BR/><BR/>The second scenario on the other hand has the pain point of making me remember to register a service with the container every single time I create a new one. That gets even worse if you inject your controllers, since these tend to be created fairly often (every time some new functionality comes, usually you get a new controller).<BR/><BR/>Even so, I loved the post! Way to go Martin.<BR/><BR/>Bernardo HeynemannBernardo Heynemannhttp://www.blogger.com/profile/13719132951779848435noreply@blogger.com