Hello Karl,
While the Provider model is a viable solution for the problem here, I believe
that a better solution might be much simpler by using the AbstractFactory
pattern [1] in conjunction with the DataMapper pattern [2].
For example:
// This class doesnt necessarily need to exist. We could create DataFactory
as an abstract class and define GetDataFactory as a static method on that
class. The choice is yours.
public class DataManager
{
public IDataFactory GetDataFactory()
{
// some code to read the configuration which will determine which
concrete implementation of IDataFactory to return
string dataFactoryType = ConfigurationSettings.AppSettings["dataFactoryType"];
Type type = Type.GetType(dataFactoryType);
return (IDataFactory)Activator.CreateInstance(type); // of course,
you'll probably want to do some caching of this
// since reflection can be expensive. Borrowing a page from the Provider
design pattern implementation, we could cache
// the ConstructorInfo object and invoke it.
// Another option would be to expose this DataManager as a singleton.
}
}
public interface DataFactory
{
IUserMapper GetUserMapper();
}
public interface IUserMapper
{
User Get(string id);
Insert(User user);
Update(User user);
Delete(User user);
}
// Data store provider implementation
class SqlDataFactory : IDataFactory
{
public IUserMapper GetUserMapper()
{
return new SqlUserMapper();
}
}
class SqlUserMapper : IUserMapper
{
// IUserMapper implementation goes here.
}
This is a great pattern to implement, because it easily allows for future
growth. Since all data access is done through the IDataFactory interface
as well as the DataMapper interfaces, the client has no concept of the underlying
data store.
The only things I have to do to add say Oracle support is implement an IDataFactory
that returns the DataMapper classes for the Oracle database.
[1]
http://c2.com/cgi/wiki?AbstractFactory
[2]
http://www.martinfowler.com/eaaCatalog/dataMapper.html