Return to Answer

An alternative to Dependancy Injection is using a Service Locator. A Service Locator is easier to understand, debug, and makes constructing an object simpler especially if you aren't using a DI framework. Service Locators are a good pattern for managing external static dependancies, for instance a database that you would otherwise have to pass into every object in your data access layer.

When refactoring legacy code, it is often easier to refactor to a Service Locator than to Dependancy Injection. All you do is replace instantiations with service lookups and then fake out the service in your unit test.

However, there are some downsides to the Service Locator. Knowing the depandancies of a class is more difficult because the dependancies are hidden in the class's implementation, not in constructors or setters. And creating two objects that rely on different implementations of the same service is difficult or impossible.

TLDR: If your class has static dependancies or you are refactoring legacy code, a Service Locator is arguably better than DI.

An alternative to Dependency Injection is using a Service Locator. A Service Locator is easier to understand, debug, and makes constructing an object simpler especially if you aren't using a DI framework. Service Locators are a good pattern for managing external static dependencies, for instance a database that you would otherwise have to pass into every object in your data access layer.

When refactoring legacy code, it is often easier to refactor to a Service Locator than to Dependency Injection. All you do is replace instantiations with service lookups and then fake out the service in your unit test.

However, there are some downsides to the Service Locator. Knowing the depandancies of a class is more difficult because the dependencies are hidden in the class's implementation, not in constructors or setters. And creating two objects that rely on different implementations of the same service is difficult or impossible.

TLDR: If your class has static dependencies or you are refactoring legacy code, a Service Locator is arguably better than DI.

An alternative to Dependancy Injection is using a Service Locator. A Service Locator is easier to understand, debug, and makes constructing an object simpler especially if you aren't using a DI framework. Service Locators are a good pattern for managing external static dependancies, for instance a database that you would otherwise have to pass into every object in your data access layer.

When refactoring legacy code, it is often easier to refactor to a Service Locator than to Dependancy Injection. All you do is replace instantiations with service lookups and then fake out the service in your unit test.

However, there are some downsides to the Service Locator. Knowing the depandancies of a class is more difficult because the dependancies are hidden in the class's implementation, not in constructors or setters. And creating two objects that rely on different implementations of the same service is difficult or impossible.

An alternative to Dependancy Injection is using a Service Locator. A Service Locator is easier to understand, debug, and makes constructing an object simpler especially if you aren't using a DI framework. Service Locators are a good pattern for managing external static dependancies, for instance a database that you would otherwise have to pass into every object in your data access layer.

When refactoring legacy code, it is often easier to refactor to a Service Locator than to Dependancy Injection. All you do is replace instantiations with service lookups and then fake out the service in your unit test.

However, there are some downsides to the Service Locator. Knowing the depandancies of a class is more difficult because the dependancies are hidden in the class's implementation, not in constructors or setters. And creating two objects that rely on different implementations of the same service is difficult or impossible.

TLDR: If your class has static dependancies or you are refactoring legacy code, a Service Locator is arguably better than DI.

An alternative to Dependancy Injection is using a Service Locator. A Service Locator is easier to understand, debug, and makes constructing an object simpler especially if you aren't using a DI framework. Service Locators are a good pattern for managing external static service dependancies, for instance a database that you would otherwise have to pass into every class in your data access layer.

When refactoring legacy code, it is often easier to refactor to a Service Locator than to Dependancy Injection. All you do is replace instantiations with service lookups and then fake out the service in your unit test.

However, there are some downsides to the Service Locator. Knowing the depandancies of a class is more difficult because the dependancies are hidden in the class's implementation, not in constructors or setters. It is difficult to create two objects that rely on different implementations of the same service.

An alternative to Dependancy Injection is using a Service Locator. A Service Locator is easier to understand, debug, and makes constructing an object simpler especially if you aren't using a DI framework. Service Locators are a good pattern for managing external static dependancies, for instance a database that you would otherwise have to pass into every object in your data access layer.

When refactoring legacy code, it is often easier to refactor to a Service Locator than to Dependancy Injection. All you do is replace instantiations with service lookups and then fake out the service in your unit test.

However, there are some downsides to the Service Locator. Knowing the depandancies of a class is more difficult because the dependancies are hidden in the class's implementation, not in constructors or setters. And creating two objects that rely on different implementations of the same service is difficult or impossible.