Making dependency injection optional by introducting a factory?

Question

So I have a piece of software containing a brunch of service classes. Those services take some dependencies though their respective constructors.

I have designed with dependency injection in mind, but developers who are going to build on top of the software, may not want to use DI. Therefore I have not implemented an IOC container, so it is up to the developer to introduce one if desired.

My problem is that the software comes with an administration website, which uses these services. I don't want to hardcode the service dependencies in the site, because I want to make it possible for the developers to switch them if they want to.

So how should I go about this?

I was thinking about introducing a factory for services, and give it a fixed static location somewhere. Then use it on the site.

public class ServiceFactory : IServiceFactory
{
    public static IServiceFactory Current { get; set; }

    static ServiceFactory()
    {
        Current = new ServiceFactory();
    }

    public TService Create<TService>()
    {
        // Creation logic here.
    }
}

Developers will be able to control things by setting their own implementation of IServiceFactory to the static ServiceFactory.Current property.

Is this the way to go?

possible duplicate of [Dependency Inject (DI) "friendly" library](http://stackoverflow.com/questions/2045904/dependency-inject-di-friendly-library) — Mauricio Scheffer, May 25 '11 at 15:12

score 2 · Answer 1 · edited May 23 '17 at 12:26

2

Two things I would like to note.

What you are proposing is not Dependency Injection, rather Service Location. They are not the same.
Ideally dependency injection is fully transparent to a developer. I.e. the true dependencies enter through the constructor and not via an indirection.

edited May 23 '17 at 12:26

Community

1
1

answered May 25 '11 at 07:54

flq

22,247
8
55
77

Yea, I know :) Trying to find some sort of middle ground. – Sir Code-A-Lot May 25 '11 at 08:24

score 1 · Accepted Answer · answered May 25 '11 at 07:46

1

Have you looked into the CommonServiceLocator library? It is designed to provide an abstraction layer over an IOC container, however you could equally use it to abstract a service factory as you describe, that way your application would be able to resolve its dependencies without necessarily knowing whether they were coming from DI or a factory implementation...

answered May 25 '11 at 07:46

MattDavey

8,897
3
31
54

So, I should ditch the static part from my factory above, use the CommonServiceLocator in the site and get a ServiceFactory from it, which in turn is able to get services with some default dependencies? – Sir Code-A-Lot May 25 '11 at 11:05
It depends on what you want to require from your library users. You could resolve all of your dependencies using the service locator itself, which might require your users to do some fairly complex configuration of their chosen IoC container; or you could resolve all your dependencies using a factory (obtaining the factory from the service locator), which is easier for your users to configure, but they might have to implement or extend the factory themselves... – MattDavey May 25 '11 at 13:20

Making dependency injection optional by introducting a factory?

2 Answers2