service-locator

I've been programming for some time but never got interested in knowing in theory what each concept means, I may be using a variety of programming concepts, but without knowing it. Service Locator : For me, refers to a record of shortcuts to speed up development by reducing the amount of code. One question is: may Locator refer to namespaces/classes only, or I can have a registry of variables? Here is my understanding of it: $locator = new ServiceLocator() $locator->set('app', new System\Application()); $locator->set('db', new System\Pdo()); // Get the objects $locator->get('db')->connect();

I've been looking at the Common Service Locator as a way of abstracting my IoC container but I've been noticing that some people are strongly against this type of this. Do people recommend never using it? Always using it? or sometimes using it? If sometimes, then in what situations would you use it and what situations would you not use it. Ian Ringrose Imagine you are writing library code to be used by 3rd party developers. Your code needs to be able to create service objects that these developers provide. However you don’t know which IoC container each of your callers will be using. The

Something that has been bugging me since I read an answer on another stackoverflow question (the precise one eludes me now) where a user stated something like " If you're calling the Service Locator, you're doing it wrong. " It was someone with a high reputation (in the hundred thousands, I think) so I tend to think this person might know what they're talking about. I've been using DI for my projects since I first started learning about it and how well it relates to Unit Testing and what not. It's something I'm fairly comfortable with now and I think I know what I'm doing. However, there are a

What are the advantages and disadvantages of using a Service Locator versus a singleton? I've read that singletons are bad but I'm wondering if s Service Locator would be generally a better way of doing things. Both approaches are bad in that it's not obvious from class contract what are its' dependencies. That is, private void foo() { var x = SomeSingleton.Instance.GetX(); var y = ServiceLocator.GetService<IProvider>().GetY(); } has references to SomeSingleton and IProvider buried deep somewhere inside. However, compared to pure singleton approach, service locators are generally much better

I am really confused on when to use getServiceLocator and when not to. As an example: + Module -+ Helloworld --+ src ---+ Controller ----+ IndexController.php ----+ IndexControllerFactory.php ---+ Service ----+ LogginService.php ----+ GreetingService.php ----+ GreetingServiceFactory.php GreetingServiceFactory.php has the content: <?php namespace Helloworld\Service; use Zend\ServiceManager\FactoryInterface; use Zend\ServiceManager\ServiceLocatorInterface; class GreetingServiceFactory implements FactoryInterface { public function createService (ServiceLocatorInterface $serviceLocator) {

After reading "Dependency Injection in .NET" by Mark Seemann I stay away from the Service Locator which is an anti-pattern. Upon reading the release notes on MVC 4 I see: Improved Inversion of Control (IoC) via DependencyResolver: Web API now uses the service locator pattern implemented by MVC’s dependency resolver to obtain instances for many different facilities. Thus I'm left curious and confused why Microsoft would use a service locator in 2012. That's an implementation detail that you shouldn't care about. The important thing is that now that the Web API uses the DependencyResolver to

I am hearing people say you should not use Service Locator for your Dependency Injection. So how exactly do you inject the dependencies without relying on a service locator? I want to try out IoC containers, but don't want to land into an anti-pattern. Should you just set everything up so there is one place where all classes always have a dependency chain to the deepest classes? (if I/that makes sense at all) I isn't right to have all your code littered with dependencies on the IoC container of choice, is it? So where do you "use" your the container (for rexolving)? And how do you get it to

I'm trying to remove a Service Locator from an abstract base class, but I'm not sure what to replace it with. Here is a psuedo-example of what I've got: public abstract class MyController : Controller { protected IKernel kernel; public MyController(IKernel kernel) { this.kernel = kernel); } protected void DoActions(Type[] types) { MySpecialResolver resolver = new MySpecialResolver(kernel); foreach(var type in types) { IMyServiceInterface instance = resolver.Get(type); instance.DoAction(); } } } The problem with this is that the instanciator of a derived class doesn't know what bindings the