Simple Factory with parameter condition, using Unity 2.0

Question

Let's say I have a Simple Factory (SimpleProductFactory) that uses a condition parameter to determine how to create Products like this:

public static class SimpleProductFactory
{
    public static Product MakeProduct(Condition condition)
    {
        Product product;
        switch(condition)
        {
            case Condition.caseA:
                product = new ProductA();
                // Other product setup code
                break;
            case Condition.caseA2:
                product = new ProductA();
                // Yet other product setup code
                break;
            case Condition.caseB:
                product = new ProductB();
                // Other product setup code
                break;
        }
        return product;
    }
}

This factory is used by some client that handles runtime data containing the condition like this:

public class SomeClient
{
    // ...
    public void HandleRuntimeData(RuntimeData runtimeData)
    {
        Product product = SimpleProductFactory.MakeProduct(runtimeData.Condition);
        // use product...
    }
    // ...
}

public class RuntimeData
{
    public Condition Condition { get; set; }
    // ...
}

How can I achieve the same construction behavior using Unity 2.0?
The important part is that the condition (Condition) determines how to create and setup the Product, and that the condition is only known at runtime and differs for each MakeProduct(...) call. (The "Other product setup code" deals with some delegate stuff, but could also be handling other initializations, and needs to be part of the construction.)

How should the container registration of Product (or an IProduct inteface) be done?
Should I use an InjectionFactory construction? How do I do that?

// How do I do this?
container.RegisterType<Product>(???)

What do I need to do to be able to supply the condition in the client code?

Naïve client code (from a previous edit) to highlight the last question, that explains the wordings of a couple of the answers:

public class SomeClient
{
    // ...
    public void HandleRuntimeData(RuntimeData runtimeData)
    {
        // I would like to do something like this,
        // where the runtimeData.Condition determines the product setup.
        // (Note that using the container like this isn't DI...)
        Product product = container.Resolve<Product>(runtimeData.Condition);
        // use product...
    }
    // ...
}

_{(I have read through a lot of similar questions here at Stackoverflow but haven't been able to fit them, and their answers, to my needs.)}

Answer 1

You should not inject or use the container in your classes in any way. This includes the use of parameters. The reason for this is that doing so will bind your code to the container. You will then be left with a lot of work if you ever have to implement another container or even a new version.

However for the case your describing Unity (and some other injection frameworks) has a feature that is called 'automatic factory'. It uses the .NET Func<TResult> delegate. This is a .NET feature so it doesn't tie your class to Unity.

This is how to use it, first register your service. Do not register it with a ContainerControlledLifetimeManager or you will get the same instance every time.

unity.RegisterType<IOpenFileService, OpenFileService>();

Then register an automatic factory for it.

unity.RegisterType<Func<IOpenFileService>>();

This can then be injected in any class that needs it.

unity.RegisterType<ViewModelBase, OptionsFileLocationsViewModel>(
    new InjectionConstructor(new ResolvedParameter<Func<IOpenFileService>>());

If you now resolve an instance of OptionsFileLocationsViewModel it will not be injected with an instance of IOpenFileService but with a function that if called will return an instance of IOpenFileService.

private readonly Func<IOpenFileService> openFileServiceFactory;

private string SelectFile(string initialDirectory)
{
    var openFileService = this.openFileServiceFactory();
    if (Directory.Exists(initialDirectory))
    {
        openFileService.InitialDirectory = initialDirectory;
    }
    else
    {
        openFileService.InitialDirectory =
            System.Environment.GetFolderPath(System.Environment.SpecialFolder.Desktop);
    }

    bool? result = openFileService.ShowDialog();
    if (result.HasValue && result.Value)
    {
        return openFileService.FileName;
    }

    return null;
}

I hope this brief explanation of mine will inspire you to solve your issue.

Answer 2

you may do define unique names for your registrations;

container.RegisterType<Product ,ProductA>("ProductA");
container.RegisterType<Product, ProductB>("ProductB");

or in configuration file;

<register type="Product" mapTo="ProductA" name="ProductA" />
<register type="Product" mapTo="ProductB" name="ProductB" />

then you may resolve the instance based on the registration:

string productName = "ProductB";
Product product = container.Resolve<Product>(productName);

You may also use a class like the following for names;

public class ProductTypes
{
    public static string ProductA
    {
        get
        {
            return "ProductA";
        }
    }

    public static string ProductB
    {
        get
        {
            return "ProductB";
        }
    }
}

then;

container.RegisterType<Product,ProductA>(ProductTypes.ProductA);
container.RegisterType<Product,ProductB>(ProductTypes.ProductB);

and resolve it;

Product product = null;

switch(condition)
{
    case Condition.caseA:
        product = container.Resolve<Product>(ProductTypes.ProductA);
        // Other product setup code
        break;
    case Condition.caseA2:
        product = container.Resolve<Product>(ProductTypes.ProductA2);
        // Yet other product setup code
        break;
    case Condition.caseB:
        product = container.Resolve<Product>(ProductTypes.ProductB);
        // Other product setup code
        break;
}

return product;