Ayende @ Rahien

Francois Tanguay commented on Service locator for optional dependencies

Sun, 13 Jan 2008 17:30:39 GMT

Given, it hides dependencies. They aren't enforced. So are method calls on dynamic languages. For dynamic languages, people argue that it is good test coverage that ensures success... Couldn't it be the same thing for service locator? There are some pros and cons to any approach. Cons of Service Locator are definitely related to how explicit are the dependencies. Pros are lazy creation of depencies (I find app initialization time to be generaly better) Also, I've been using extensions methods on IServiceLocator to ease cross-cutting concern usage. e.g. interface IServiceLocator { T Resolve(); } interface IServiceLocatorClient { IServiceLocator Locator { get; set; }} public static class LoggerExtensions { public static void Log(this IServiceLocatorClient client, string msg) { client.Locator.Resolve().Log(msg); } } With IoC: public class Foo : IServiceLocatorClient { public IServiceLocator { get; set; } //THE only dependency that has to be injected. void Do() { try { ... } catch (Exception ex) { this.Log(exception.Message); } } }

Ayende Rahien commented on Service locator for optional dependencies

Sun, 13 Jan 2008 15:41:51 GMT

Francois, I _really_ don't like this approach. It is opaque, it hides the dependencies and it makes it easier to fail late rather than early.

Francois Tanguay commented on Service locator for optional dependencies

Sun, 13 Jan 2008 15:07:52 GMT

Ok, I probably don't have the same definition of "optional" dependency. Let's say logging is something I just do when exceptions are thrown. If exceptions never happen, I don't need an instance of ILogger. With Ioc, dependencies are resolved at config time. WIth service locator, they are resolved at runtime, on demand. Ioc: try { ...} catch (Exception ex) { MyInjectedLogger.Log(ex); } ServiceLocator: try { ...} catch (Exception ex) { SerivceLocator.Resolve.Log(ex); }

Ayende Rahien commented on Service locator for optional dependencies

Sat, 12 Jan 2008 15:42:46 GMT

Francois, Absolutely not. If I want to use optional dependencies using DI (like I should), I just put a property. This is for infrastructure concerns more than anything else

Francois Tanguay commented on Service locator for optional dependencies

Sat, 12 Jan 2008 15:31:21 GMT

If I understand correcly, you end up with two different mechanisms to get your dependencies depending whether they're optional or not. That's why I prefer to fo with a service locator all the way.

Ayende Rahien commented on Service locator for optional dependencies

Sat, 12 Jan 2008 11:07:19 GMT

It is used for service location, mostly. I don't like it, but it is really useful when you want to use IoC on things like static classes.

Andrey Shchekin commented on Service locator for optional dependencies

Sat, 12 Jan 2008 10:25:03 GMT

Can you explain the use cases of IoC.Resolve<>? The thing I do not completely understand is which classes get their dependencies through dependency injection and which use Resolve?

Ayende Rahien commented on Service locator for optional dependencies

Sat, 12 Jan 2008 09:03:47 GMT

Joshua, Yes, it would. The problem is that I am writing a library, and I don't want to force the users of the library to define certain things on the container.

Joshua McKinney commented on Service locator for optional dependencies

Sat, 12 Jan 2008 08:25:14 GMT

I'm not sure I understand. Wouldn't it have been better to just set put NullLogger in the IoC container in the first place? Doesn't this kinda defeat the purpose of IoC? Perhaps better would be to extend the container much like the auto mocking container to provide a NullService for non resolvable dependencies.