Ideatryout: Typed Providerfactory

Question

I've been thinking about starting a new project in C#.NET (4.0RC) for a couple of days now. The end result of the project would be a class-library consisting of what I for now call a "ProviderFactory", a couple of interfaces (or abstract classes) and a default "ProviderType" or two.

First of all I might need/decide to change the naming of my classes not to clash with what's already in .NET. Secondly it's a good chance that what I'm describing here already exists (it might even be within .NET natively without me knowing about it), so if that's the case a single link to that project or a tutorial would be appreciated.

The functionality I'm thinking about is not just a factory that can provide me with a simple Provider, but it should be able to generate any kind of Provider. I want to be able to write something like this:

BlogProvider bp = ProviderFactory.GetProvider<BlogProvider>();

and it should return the current selected BlogProvider, or null if there is none. Also I want to be able to provide a list over all the available providers of one type like for instance

string[] blogproviders = ProviderFactory.GetRegisteredProviders<BlogProvider>();

and it should return an array of strings with blog-providers (like "ODBCBlogProvider", "XMLBlogProvider", etc.). I also need to be able to set the current provider, for instance like this:

ProviderFactory.SetCurrentProvider<BlogProvider>("ODBCBlogProvider");

This should make the current BlogProvider the ODBCBlogProvider, so that next time I call ProviderFactory.GetProvider() it should return an instance of ODBCBlogProvider (which of cause need to extend the BlogProvider base class).

Also, every ProviderType (or ProviderBase if you like) needs to have a ProviderTypeName (BlogProvider) and a ProviderTypeDisplayName ("Blog" or "Blog provider") that is unique to that ProviderType, and every Provider that extends that provider needs to have a ProviderName (ODBCBlogProvider) and a ProviderDisplayName ("ODBC" or "ODBC blog" etc.). The ProviderName and ProviderTypeName could just for simplicity be there class-names gained by reflection.

This probably means that I'd need an interface for the ProviderBase, something like this:

public interface ProviderBase
{
    string ProviderName { get; } // The display-name.
    string Description { get; } // A description of the provider type, like "This provides you with a blog."
}

And for the BlogProvider I'd need to create a abstract class that implements those two members and creates methods for the actual BlogProviders to override.

public abstract class BlogProvider : ProviderBase
{
    public string ProviderName
    {
        get { return "Blog"; }
    }

    public string Description
    {
        get { return "This provides you with a blog."; }
    }

    public abstract int GetPostCount();
}

Then, somewhere in my code I'd had to run something like

ProviderFactory.RegisterProviderType(typeof(BlogProvider));

or an even better option would be to be able to use attributes like this:

[Provider("Blog", "This provides you with a blog.")]
public interface BlogProvider
{
    int GetPostCount();
}

I don't see the need to use an abstract class with this approach because none of the members needs to be set in the base class. Also the need for the ProviderBase-interface is gone. The ideal thing would of cause be if the ProviderFactory could just find all the classes/interfaces containing the ProviderAttribute, and than ODBCBlogProvider would just need to implement BlogProvider, but I'm not certain how I do this, especially not when it's a requirement that the providers and providertypes can both come for external assemblies.

Another requirement of the ProviderFactory is that it should work both when in a stateless environment and in a environment where it is kept alive, thus it should be able to save settings to some config-file/stream/database (something like that, doesn't really matter) on change and load from this at initialization, but this should be optional. Thus it would also work on the web (having a blog on your own machine doesn't give too much sense).

One more requirement is that the Providers might require other Providers to work. For instance, and AudiEngine might only work with an AudiCar, however an AudiCar can run perfectly with an BmwEngine.

Also (and I'm not sure where to put that yet, maybe an optional attribute on the provider-class itself) every provider should have the option to be singleton or not.

That is all I can think of for now. Any input on how this should be implemented or weather there already is a implementation out there would be greatly appreciated, and anything can be changed because I haven't written any code yet, this is all something I've been thinking about for now.

Answer 1

Well, it looks like an overengineered (rather, overly-fancy-named) IoC/DI container.

The idea of IoC is pretty much the same, with the exception that they (containers) do not require your "collaborators" to implement any interfaces or derive from base classes:

var builder = new ContainerBuilder();
builder.Register<Car>();
builder.Register<Engine>().As<IEngine>();

var container = builder.Build();

// somewhere in the code
var car = container.Resolve<Car>();

This is an example using autofac, which is one of a myriad of DI containers for C#/.NET.

Answer 2

As @Anton indicates, this is close to a IoC/DI container. Again, using Autofac, you can get a long way doing something like this:

var builder = new ContainerBuilder();
builder.Register<Car>();
builder.Register<BmwEngine>();
builder.Register<AudiEngine>();
builder.Register<DefaultEngine>();
builder.Register<EngineSelector>().As<IEngineSelector>().SingletonScope();

builder.Register(
    c => {
            var selector = c.Resolve<IEngineSelector>();
            switch(selector.CurrentEngine)
            {
                case "bmw":
                    return c.Resolve<BmwEngine>();
                case "audi":
                    return c.Resolve<AudiEngine>();
                default:
                    return c.Resolve<DefaultEngine>();
            }
        }
    ).As<IEngine>().FactoryScoped();

var container = builder.Build();

// somewhere in the code
var selector = container.Resolve<IEngineSelector>();
selector.CurrentEngine = "bmw";

var car = container.Resolve<Car>();