service-locator | 易学教程

Singleton Vs ServiceLocator

阅读更多关于 Singleton Vs ServiceLocator

问题 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. 回答1: 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

ZF2 when to use getServiceLocator() and when not to

阅读更多关于 ZF2 when to use getServiceLocator() and when not to

问题 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

What is the difference between using the Service Locator anti-pattern and using the Castle Windsor container?\" [closed]

阅读更多关于 What is the difference between using the Service Locator anti-pattern and using the Castle Windsor container?\" [closed]

Recently, I have been trying to understand what is the difference between using the Service Locator "anti-pattern" and using the Castle Windsor container. I have found some info here and there on the Internet and I have summarized what I have learned so far in an unfinished blog post . EDIT: Until now I have been thinking that Dependency Injection is all one would need to guarantee separation. But everywhere I look I see a push in the direction of containers such as Castle Windsor. I would like to clearly understand the reasons. Please... Explain this to me like I'm a 6 year old :) Mark

How to avoid Service Locator Anti-Pattern?

阅读更多关于 How to avoid Service Locator Anti-Pattern?

问题 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(); } }

Static members class vs. normal c-like interface

阅读更多关于 Static members class vs. normal c-like interface

问题 Hey there. After reading here about the Service Locator pattern, it got me thinking wether a class with only static members really is the way to go, or if a normal c-like interace wouldn't be more appropriate. I see people throwing around the class keyword all the time when they don't even need it. Example with static members class taken from the linked page: class Locator { public: static IAudio* GetAudio() { return service_; } static void Register(IAudio* service) { service_ = service; }

Is it bad to use servicelocation instead of constructor injection to avoid writing loads of factory classes

阅读更多关于 Is it bad to use servicelocation instead of constructor injection to avoid writing loads of factory classes

问题 Right now we use DI/IOC and when we need to pass extra parameters to a constructor we use a factory class e.g. public class EmailSender { internal EmailSender(string toEmail, string subject,String body, ILogger emailLogger) {.....} } public class EmailSenderFactory { ILogger emailLogger; public EmailSenderFactory(ILogger emailLogger) { this.emailLogger = emailLogger; } public EmailSender Create(string toEmail, string subject, string body) { return new EmailSender(toEmail, subject, body,

Is IDependencyResolver an anti-pattern?

阅读更多关于 Is IDependencyResolver an anti-pattern?

I am designing some architectural changes into a legacy ASP.NET application. I prototyped some classes for dependency resolution that mimic the ASP.NET MVC's IDependencyResolver. I won't post because it is pretty much the same interface, but in other natural language. I figured out it might be considered Service Location, which in turn is usually (not fully in some cases) condemned in favor of Dependency Injection. Nevertheless, I couldn't find any recommendation against the use of the ASP.NET MVC's dependency resolution implementation. Is the ASP.NET MVC's IDependencyResolver considered an

What is the difference between using the Service Locator anti-pattern and using the Castle Windsor container?" [closed]

阅读更多关于 What is the difference between using the Service Locator anti-pattern and using the Castle Windsor container?" [closed]

问题 Closed . This question needs to be more focused. It is not currently accepting answers. Want to improve this question? Update the question so it focuses on one problem only by editing this post. Closed 2 years ago . Recently, I have been trying to understand what is the difference between using the Service Locator "anti-pattern" and using the Castle Windsor container. I have found some info here and there on the Internet and I have summarized what I have learned so far in an unfinished blog

Is IDependencyResolver an anti-pattern?

阅读更多关于 Is IDependencyResolver an anti-pattern?

问题 I am designing some architectural changes into a legacy ASP.NET application. I prototyped some classes for dependency resolution that mimic the ASP.NET MVC\'s IDependencyResolver. I won\'t post because it is pretty much the same interface, but in other natural language. I figured out it might be considered Service Location, which in turn is usually (not fully in some cases) condemned in favor of Dependency Injection. Nevertheless, I couldn\'t find any recommendation against the use of the ASP

Dependency Injection vs Service Location

阅读更多关于 Dependency Injection vs Service Location

问题 I am currently weighing up the advantages and disadvantages between DI and SL. However, I have found myself in the following catch 22 which implies that I should just use SL for everything, and only inject an IoC container into each class. DI Catch 22: Some dependencies, like Log4Net, simply do not suit DI. I call these meta-dependencies and feel they should be opaque to calling code. My justification being that if a simple class \'D\' was originally implemented without logging, and then