这是服务定位器的反模式，并且是较差的解决方案吗？

Question

I have implemented a solution that has some core reusable classes that are easily registered and resolved using StructureMap. I then have an abstract factory to load additional families of products at runtime.

If I have a StructureMap registries like this one:

    public ProductAClaimsRegistry()
    {           
        var name = InstanceKeys.ProductA;

        this.For<IClaimsDataAccess>().LifecycleIs(new UniquePerRequestLifecycle()).Use<ProductAClaimsDataAccess>().Named(name)
            .Ctor<Func<DbConnection>>().Is(() => new SqlConnection(ConfigReader.ClaimsTrackingConnectionString));

        this.For<IClaimPreparer>().LifecycleIs(new UniquePerRequestLifecycle()).Use<ProductAClaimPreparer>().Named(name);

        this.For<IHistoricalClaimsReader>().LifecycleIs(new UniquePerRequestLifecycle()).Use<ProductAHistoricalClaimReader>().Named(name);

        this.For<IProviderClaimReader>().LifecycleIs(new UniquePerRequestLifecycle()).Use<ProductAProviderClaimReader>().Named(name);    
    }

There may be a version for ProductB , ProductC and so on.

My abstract factory then loads the correct named instance like this:

public abstract class AbstractClaimsFactory 
{              
    private IClaimsReader claimsReader;
    private IClaimPreparer claimPreparer;

    protected string InstanceKey { get; set; }

    public virtual IClaimsReader CreateClaimReader()
    {
        return this.claimsReader;
    }

    public virtual IClaimPreparer CreateClaimPreparer()
    {
        return this.claimPreparer;     
    }

    public void SetInstances()
    {
        this.CreateInstances();

        var historicalReader = ObjectFactory.Container.GetInstance<IHistoricalClaimsReader>(this.InstanceKey);
        var providerReader = ObjectFactory.Container.GetInstance<IProviderClaimReader>(this.InstanceKey);

        this.claimsReader = new ClaimsReader(historicalReader, providerReader);

        this.claimPreparer = ObjectFactory.Container.GetInstance<IClaimPreparer>(this.InstanceKey);
    }

    protected abstract void CreateInstances();
}

At runtime there is a processor class that has a concrete factory injected like this:

   public void Process(AbstractClaimsFactory claimsFactory)
   { 
       // core algorithm implemented                        
   }

A concrete factory then exists for each product:

public class ProductAClaimsFactory : AbstractClaimsFactory
{       
    public ProductAClaimsFactory()
    {
        SetInstances();
    }

    protected override void CreateInstances()
    {
        InstanceKey = InstanceKeys.ProductA;
    }                   
}

EDIT

The classes loaded in the factory are used by other classes that are Product agnostic - but they need to inject ProductA or ProductB behaviour.

    public ClaimsReader(IHistoricalClaimsReader historicalClaimsReader, IProviderClaimReader providerClaimsReader)
    {
        this.historicalClaimsReader = historicalClaimsReader;
        this.providerClaimsReader = providerClaimsReader;          
    }

I'm not exactly sure if this a text book abstract factory pattern and I'm new to StructureMap and more advance DI in general.

With this solution I think I have enforced a core algorithm and reused code where appropriate.

I also think that it is extensible as ProductN can easily be added without changing existing code.

The solution also has very good code coverage and the tests are very simple.

So, bottom line is: I am fairly happy with this solution but a colleague has questioned it, specificly around using ObjectFactory.Container.GetInstance<IClaimPreparer>(this.InstanceKey); to load named instances and he said it looks like the Service Locator anti pattern .

Is he correct?

If so, can anyone point out the downsides of this solution and how I might go about improving it?

Answer 1

This is service location. It's a problem as you have introduced a dependency on your service locator, ObjectFactory , rather than the interface, IClaimPreparer , your AbstractClaimsFactory class actually needs. This is going to make testing harder as you'll struggle to fake an implementation of IClaimPreparer . It also clouds the intention of your class as the class's dependencies are 'opaque'.

You need to look into the use of a Composition Root to resolve the anti-pattern. Have a look at Mark Seemann's work to find out more.

Answer 2

He's partially correct. Given a good DI container it is possible to register all your components and resolve the root object in your object tree... the DI container handles creating all the dependency for the root object (recursively) and creates the whole object tree for you. Then you can throw the DI container away. The nice thing about doing it that way is all references to DI container are confined to the entry-point of your app.

However, you are at least one step ahead of the curve since you didn't resolve dependencies in the constructor (or somewhere else) of the object using them, but instead resolved those in the factory and passed them in to the objects that need them via constructor-injection ;) (That's something I see often in code I work on and that is definitely an anti-pattern.

Here's a bit more about service locators and how they can be an anti-pattern: http://martinfowler.com/articles/injection.html http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/

Here's a bit more about the configure-resolve-release type pattern I hinted at: http://blog.ploeh.dk/2010/08/30/Dontcallthecontainer;itllcallyou/ http://kozmic.net/2010/06/20/how-i-use-inversion-of-control-containers/