I'm Keyvan Nayyeri, a 25 years old Ph.D. student at
the Computer Science department of
the University of Texas at San Antonio.
I'm also
a Software Architect and Developer and previously held a B.Sc.
degree in Applied Mathematics.
This is my blog where I publish content about various topics specifically Programming Languages and Compilers, Software
Engineering and Programming.
Last Friday I started a post series about building a provider model from the scratch.
In the first post I gave a quick overview of the steps that should be followed to get this done and then discussed about two topics in details: The first topic was about the main classes that you need to use in the provider model and the second topic was about the configuration system for the provider.
And now here is the second part with a detailed discussion about the abstract part of the provider model.
After building the basic parts of the provider model, you surely need to build the abstraction part of your provider. As you know from your experiences from various provider models, a provider model has an abstraction as well as many implementations that developers can do. The topic of this post is that abstraction.
As is obvious, you need to create an abstract base class to achieve this abstraction. What you write in this class consists of some stuff that are required for the provider model as well as some stuff that varies based on your own provider model.
I create this abstract class and call it SampleDataProvider.
using System;
using System.Data;
using System.Configuration;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Linq;
namespace ProviderModelSample.Code
{
public abstract class SampleDataProvider
{
}
}
First of all, you need to have a unique name for the provider that will be used in the configuration for it. You can define this string name in a static read only field for your class.
public abstract class SampleDataProvider
{
#region Fields
public static readonly string SampleDataProviderName = "SampleDataProvider";
#endregion
}
After this, you need to keep a default instance of the implementation of your provider. This default instance can be cached in the memory to be used several times by your code. To do this you need to define an instance of your provider class and set it to the appropriate value. This appropriate value comes from a private static method that is called inside the static constructor of your class.
#region Instance
private static SampleDataProvider _defaultInstance = null;
static SampleDataProvider()
{
CreateDefaultSampleDataProvider();
}
private static void CreateDefaultSampleDataProvider()
{
SampleConfiguration config = SampleConfiguration.Get();
DataProvider sampleProvider = (DataProvider)config.Providers[SampleDataProviderName];
_defaultInstance = DataProviders.CreateInstance(sampleProvider) as SampleDataProvider;
}
#endregion
As you see, CreateDefaultSampleDataProvider retrieves the list of defined providers in the configuration file and gets the appropriate provider instances based on the unique name that you have defined. It then passes this provider instance to the DataProviders.CreateInstance function to get a provider instance and set the default provider.
On the other hand, you need to be able to get this default instance from your provider somehow. So you need to define two public static methods that return instances of your provider class. I call these methods Instance. One of these functions is suitable when you want to use your provider and you'll read about it in the next part of this post series and the second method is suitable to retrieve the implementation from the abstraction based on the defined configuration for the implementation class. This method gets an instance of the DataProvider class. Here DataProviders.Invoke method comes into the play. You read about it in the first post of this series.
public static SampleDataProvider Instance()
{
return _defaultInstance;
}
public static SampleDataProvider Instance(DataProvider dataProvider)
{
SampleDataProvider sampleDataProvider = DataProviders.Invoke(dataProvider) as SampleDataProvider;
return sampleDataProvider;
}
Alright, you're almost done! The last step is to define your abstract methods in the class to be implemented by different provider types. I just define a single method but you can write as many methods as you want.
#region Base Methods
public abstract void AddItem(int number);
#endregion
So finally the whole code for the abstract class is this:
using System;
using System.Data;
using System.Configuration;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Linq;
namespace ProviderModelSample.Code
{
public abstract class SampleDataProvider
{
#region Fields
public static readonly string SampleDataProviderName = "SampleDataProvider";
#endregion
#region Instance
private static SampleDataProvider _defaultInstance = null;
static SampleDataProvider()
{
CreateDefaultSampleDataProvider();
}
private static void CreateDefaultSampleDataProvider()
{
SampleConfiguration config = SampleConfiguration.Get();
DataProvider sampleProvider = (DataProvider)config.Providers[SampleDataProviderName];
_defaultInstance = DataProviders.CreateInstance(sampleProvider) as SampleDataProvider;
}
public static SampleDataProvider Instance()
{
return _defaultInstance;
}
public static SampleDataProvider Instance(DataProvider dataProvider)
{
SampleDataProvider sampleDataProvider = DataProviders.Invoke(dataProvider) as SampleDataProvider;
return sampleDataProvider;
}
#endregion
#region Base Methods
public abstract void AddItem(int number);
#endregion
}
}
As you see, this was so easy to do. The next part (and hopefully the last part) will be about the implementation, configuration and application of this provider model.
Reflective Perspective - Chris Alcock » The Morning Brew #101
May 27, 2008 2:13 AM
#
Pingback from Reflective Perspective - Chris Alcock » The Morning Brew #101
Dew Drop - May 27, 2008 | Alvin Ashcraft's Morning Dew
May 27, 2008 7:02 AM
#
Pingback from Dew Drop - May 27, 2008 | Alvin Ashcraft's Morning Dew
How to Build Your Very Own Provider Model - Part 3
May 30, 2008 12:13 PM
#
In the first and second parts of this post about building a provider model from the scratch, I talked
Weekly Links #3 | GrantPalin.com
Jun 01, 2008 9:17 PM
#
Pingback from Weekly Links #3 | GrantPalin.com
My Best Blog Posts in 2008
Dec 31, 2008 1:40 PM
#
In the past 3.5 years of blogging, I haven’t had such best pick up collections in the end of the year, but now that everybody is writing one, why shouldn’t I write my own?! Collecting this list, I could realize some interesting facts that completely changed
Leave a Comment