CSharpFeeds

State Machines in C# 3.0 using T4 Templates

Andrew Matthews — Wed, 25 Jun 2008 14:07:00 -04:00

Example Code. Some time back I wrote about techniques for implementing non-deterministic finite automata (NDFAs) using some of the new features of C# 3.0. Recently I’ve had a need to revisit that work to provide a client with a means to generate a bunch of really complex state machines in a lightweight, extensible and easily understood [...]

The C# compiler is really smart, but…

luisabreu — Fri, 20 Jun 2008 10:37:00 -04:00

I’m still not understanding why it won’t give me a warning when I create an internal class with a public method. Here’s an example:

class MyInternalClass{
public void Test(){} //no compiler warning
}

Ok, at the end of the day, Test is really an “internal” method since the acessibility of a member can never be greater than the one of its containing type. But why can’t I get at least a warning? In this case, setting the method type to internal should be the “maximum” accesibility,right? There are other similar scenarios where we get the correct response from the compiler. For instance, you cannot declare a protected method on a struct. This makes sense, of course, because you can not inherit from a struct (therefore, you really don’t need to declare protected methods).

So, here we are: on the one hand, the compiler will let me declare a method as public on an internal class, even though that method will only end up beeing used on the assembly where it is defined due to the accessibility of its containing type without even generating a warning. On the other hand, the compiler won’t “relax” the protected method error on a struct type.

I’m not a compiler geek (or even a C# language expert) so the problem might really be on spec and not on the compiler. Anyway, I think that the compiler could at least generate a warning on these scenarios (internal classes with public methods). And what do you think?

Method Type Inference Changes, Part One

Eric Lippert — Tue, 17 Jun 2008 15:20:00 -04:00

I want to start this by discussing the purpose of method type inference, and clearing up some potential misunderstandings about type inference errors.

First off though, a brief note on nomenclature. Throughout this series when I say "type inference" I mean "method type inference", not any of the other forms of type inference we have in C# 3.0. (Implicitly typed locals, implicitly typed arrays, and so on.)

The purpose of type inference is to allow generic methods to be called without explicitly specifying the generic types. For example, if you have a generic method

static T Largest<T>(IEnumerable<T> list) where T : IComparable<T> { ... }

then it would be nice to be able to say

decimal maxPrice = Largest(prices);

without having to say redundant information:

decimal maxPrice = Largest<decimal>(prices);

This was useful in C# 2.0, but with the advent of extension methods and query comprehensions in C# 3.0, it is downright vital. If we made Largest into an extension method then clearly you want to be able to say

from customer in customers
from invoices in customers.invoices
select invoices.prices.Largest();

and not have to insert this ugly mechanism information into your lovely semantic query:

from customer in customers
from invoices in customers.invoices
select invoices.prices.Largest<decimal>();

When you call a method without an explicit argument list, overload resolution must figure out which method you meant to call. The way type inference works with overload resolution is that all methods of that name are put into a pool called the candidate set. If any of them are generic, we run a type inference algorithm to see if the generic type arguments can be inferred for the method. If they can, then the constructed generic method stays in the candidate set; if inference fails then it is removed. Then all methods which are inapplicable -- that is, the arguments cannot be converted to the parameter types -- are removed. Of the remaining applicable candidates, either a unique best candidate is chosen. If a unique best candidate cannot be identified then overload resolution fails.

Note that type inference failure is not actually an error in of itself. However, type inference failure (or success!) might cause real errors downstream in a number of ways. For example:

if type inference fails and the candidate set becomes empty as a result, then overload resolution fails
if type inference fails when the user intended the generic method to be the chosen one, and the remaining candidates have no unique best member, then overload resolution fails
if type inference succeeds when it wasn't expected to then there might be more methods in the candidate set than expected. If the inferred method ties for "bestness" with another candidate then overload resolution fails. (The tiebreaker rules in overload resolution are designed to avoid this scenario, but it is still possible in contrived situations.)

This then brings up the question of what error message to display when overload resolution fails. In C# 2.0 we have a heuristic which tries to detect when overload resolution failed because of the first case (which is the most common of the three cases.) In those cases it gives an error message that says "type inference failed" rather than "overload resolution failed". Even though the actual error as far as the language specification is concerned is that the candidate set contained no unique best applicable member, the user typically thinks of the cause of the error as being type inference failure in many cases, so we try to do a good job of reporting that.

It works pretty well in C# 2.0, but we struggled with this a lot in C# 3.0. Suppose you end up in a situation where you have a query:

IEnumerable<Customer> customers = ...;
var firstNames = from c in customers select c.FristName;

Oops. That is going to be translated into customers.Select(c=>c.FristName). There are no methods named "Select" on IEnumerable<Customer>, we look for extension methods and find Enumerable.Select<T, R>(this IEnumerable<T> list, Func<T, R> selector). Type inference infers T as Customer, but cannot figure out what R is because Customer does not have a property FristName. Therefore type inference fails, and therefore overload resolution fails, and therefore our heuristic takes over and gives the error that type inference failed on Select.

I think you would agree that the user does not think of the error in this program as being a failure of overload resolution or type inference; they think that the failure is that there's a typo in one clause of the query. Wes did quite a bit of work on the heuristics to go back one step further, and report why type inference failed; because the body of the lambda could not be successfully bound.

So that's one change to type inference between C# 2.0 and C# 3.0, but I seem to have gotten ahead of myself somewhat. Next time we'll take a closer look at how the mechanism of type inference works in C# 2.0.

Snippet: Ruby-like Hashes in C#

Paul Stovell — Thu, 12 Jun 2008 09:21:00 -04:00

The ASP.NET MVC team developed a URL routing engine, similar to the engine in Rails, which has made it’s way into the rest of ASP.NET. ScottGu has covered it a few times in the past, and this post has some good examples of it. Here’s a quick example: routes.MapRoute("ShowProductByCategory", "Products/Show/{Category}/{id}", new { controller [...]

Bindable LINQ: Snapshot Enumerators

Paul Stovell — Wed, 11 Jun 2008 02:47:00 -04:00

Snapshot enumerators are part of Bindable LINQ’s internal implementation which make editing collections while enumerating them possible. When you first started with .NET, you undoubtedly wrote code that looks like this: foreach (string item in strings) { if (item.StartsWith("H")) { strings.Remove(item); [...]

Bindable LINQ: Bindable Aggregates

Paul Stovell — Tue, 10 Jun 2008 02:19:00 -04:00

As with other LINQ operations, Bindable LINQ allows you to execute aggregates over values that can change over time. In the general sense, a Bindable LINQ aggregate is an operation that turns a series of values into a single value, and is not necessarily limited to numeric operations. Examples of such aggregates are classics such [...]

Tip: WPF 3.0 String.Format

Paul Stovell — Tue, 03 Jun 2008 08:53:00 -04:00

One of the upcoming additions in .NET 3.5 SP1 is a StringFormat parameter you can pass along with your bindings. Sacha Barber has an example of how to use it: <TextBlock Text="{Binding Path=AccountBalance, StringFormat='You have {0:c} in your bank account.'}" /> However, if you can’t install the service pack or you [...]

Using Postsharp for solving the inexisting multi-inheritance problem

luisabreu — Fri, 30 May 2008 14:39:00 -04:00

Well, not really...

As you surely know, you cannot have mutiple inheritance in .NET. That really sucks. Yes, I agree that multiple inheritance might bring several problems but when applied correctly, it really helps. Don't believe me? Ok, take a look at WTL.

Back to .NET...Since we can't use multiple inheritance, we end up defining several interfaces and injecting classes that implement the generic boilerplate code for those interfaces. With Windsor (or any other existing container), we're able to reduce the necessary code to instantiante an object but we still need to implement all the members of the interfaces that our base class extends. In practice, implementing this methods means redirecting those calls to instance fields that are initiated through injection.

Today I had some free time and I've decided to play with Postsharp. One of the things you can do with it is replace this manual tedious work and get all those interfaces implemented automatically during compilation. To achieve this, we need to create a new custom (or should I say, derived) CompositionAspect attribute and apply it the class we want to extend.

Since I really didn't had much time, I decided to implement something simple and really chose a bad example: the INotifyPropertyChanged interface. I say unfortunately because, as you'll see, I've ended up firing the event from a field change and this made me develop and additional attribute that is used for intercepting field changes (this was necessary due to the way events work). anyway, let's get started. The first thing we need is a general implementation for the interface. Here's one good enough for demo code:

public class PropertyChangedGeneralNotification : INotifyPropertyChanged
{
private readonly Object _firingObject;

        public PropertyChangedGeneralNotification(Object firingObject)
        {
            _firingObject = firingObject;
        }
        public event PropertyChangedEventHandler PropertyChanged;

        public void OnPropertyChanged(PropertyChangedEventArgs e)
        {
            if( PropertyChanged != null)
            {
                PropertyChanged(_firingObject, e);
            }
        }
}

This interface defines only one member: an event. My initial idea was to really build a simple class that had only the necessary event. Then, the final injected class would simply fire it. Unfortunately, you cannot do that since you can only "use events like delegates" on the class they're defined (I'm sure there really is a good reason on why there is such a strong relationship between events and the classes where they are defined, but I still haven't found a definitive answer for it - btw, if you know, please put it in the comments).

Anyway, that's why I ended up adding the OnPropertyChanged method and added a constructor which receives a reference to the object that is being injected (we need this because when we fire the event we must pass a reference to that class as the first parameter to the method that handles the event).

Ok, Now we need to build the class that is responsible for injecting the previous generic class. To achieve that, we need to create a new CompositionAspect derived class. This class must be serializable and we can override several methods to control the output of the class to which the attribute is going to be applied. Here's the code I've got:

[Serializable]
public class AOPInterfaceInjectionAttribute : CompositionAspect
{
        public override object CreateImplementationObject(InstanceBoundLaosEventArgs eventArgs)
        {
            return new PropertyChangedGeneralNotification(eventArgs.Instance);
        }

        public override Type GetPublicInterface(Type containerType)
        {
            return typeof (INotifyPropertyChanged);
        }

        public override CompositionAspectOptions GetOptions() {
            return CompositionAspectOptions.GenerateImplementationAccessor;
        }
}

The GetPublicInterface method is responsible for returning the type of the public interface that the injected class will implement. The CreateImplementationObject method must return an object that implements the referenced interface (in this case, we're returning an instance of the general class we've implemented in the previous snippet). Notice that we're using the InstanceBoundLaosEventArgs to get a reference to the instance that is being injected and passing it to our general class so that the correct reference is passed when the PropertyChanged event is fired.

The final thing you should note is the override of the GetOptions method. We're saying that in this case we should be able to get a reference to the class that is injected. This means that our "injected" class will also implement the IComposed<T> interface, which has methods that will let us get a reference to that object.

Applying this attribute to an existing class is all that is necessary for exposing the interface:

[AOPFieldChangedInjection]
public class Student
{
public String Name { get; set; }
public Int32 Age { get; set; }
}

Now, the only thing that is missing is generating the event. In this case, I though it would be fun to go ahead and create an attribute that intercepts field calls (ok, I know that this is not really the best approach, but at least I can have some more fun and learn more about the platform). When we need to intercept field calls, we can extend the OnFieldAccessAspect class. Here's what I've done:

[Serializable]
public class AOPFieldChangedInjectionAttribute : OnFieldAccessAspect
{
       public override void OnSetValue(FieldAccessEventArgs eventArgs)
       {
           var shouldFireChangedEvent = !eventArgs.ExposedFieldValue.Equals(
                                             eventArgs.StoredFieldValue);
           //call base to change the value of the field
           base.OnSetValue(eventArgs);
           //check if event should be fired
           if (shouldFireChangedEvent)
           {
               InstanceCredentials credentials = eventArgs.InstanceCredentials;
               var composedInteface = (IComposed<INotifyPropertyChanged>) (eventArgs.Instance);
               var evtHandler = (PropertyChangedGeneralNotification) composedInteface.GetImplementation(credentials);

               if (evtHandler != null)
               {
                   evtHandler.OnPropertyChanged(new PropertyChangedEventArgs(eventArgs.FieldInfo.Name));
               }
           }
       }
}

Overriding the OnSetValue is necessary if you want to intercept a write operation. I start by comparing the old value with the new value that is being saved to the field before callilng the base's method. The interesting part is the code necessary for firing the event. We start by getting the credentials. This is a nice concept that is used to prevent access from any code to the implementation code; only code that knows the credentials can access the implementation of the interface.

Notice that in this case we end up casting the interface to the class so that we can call the method that ends up generating the event (no, I can't say that I like the previous code but I can live with it since I'm writing testing exploratory code). As you can see, we end up passing the name of the field instead of passing the name of the property (again, I said that my example was poor, right?)

What matters is that now it's really easy to reuse our generic code, as you can see from the next class (which should really be in a different assembly from the one that showed the previous code):

[AOPInterfaceInjection]
[AOPFieldChangedInjection]
public class Student
{
public String Name { get; set; }
public Int32 Age { get; set; }
}

After compiling, the previous class will implement interfaces INotifyPropertyChanged and IComposed<INotifyPropertyChanged> and you'll get events fired when you change any of its properties.

There are still lots of stuff you can do with Postsharp. My first impressions are good: with this platform it's really easy to apply AOP to our projects. I'm still not convinced that this is best thing in thw world, but I'll keep playing with it and see how it reduces the code that I need to write on my day-to-day scenarios.

How to Build Your Very Own Provider Model - Part 3

Keyvan Nayyeri — Fri, 30 May 2008 16:30:00 -04:00

In the first and second parts of this post about building a provider model from the scratch, I talked about some main steps of the process. In the first part I talked about main classes in the provider model as well as the configuration system and in the second part I talked about the abstract part of the model.

Now in the third and last part of this series I want to finish the discussion by giving some details about the latest steps of the process including the implementation of the abstract layer, configuring the provider model and finally using it.

Implementation

One of the obvious steps of building the provider model is implementing the abstract layer based on your own requirements and logic. I talked about the abstract layer in the last part of this series and now I want to implement it.

As you can guess, this implementation is nothing but deriving from the abstract base class that you created for your abstraction.

There is nothing special for this inheritance except that you need to consider the constructor that you had defined for your provider when implementing this class. So for my example, I need to have a public constructor with two parameters. First one is the connection string and second one is a NameValueCollection of my custom attributes. Here and for simplicity, I don't care about the custom attributes but you can retrieve your attributes from the collection via the constructor.

Regarding this stuff, here is the final implementation of my provider based on SQL Server as the data storage.

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;
using System.Collections.Specialized;
using System.Data.SqlClient;
 
namespace ProviderModelSample.Code
{
    public class SampleSqlDataProvider : SampleDataProvider
    {
        #region Fields
 
        private string _connectionString = string.Empty;
        private NameValueCollection _attributes = new NameValueCollection();
 
        #endregion
 
        #region Constructors
 
        public SampleSqlDataProvider(string connectionString, NameValueCollection attributes)
        {
            this._connectionString = connectionString;
            this._attributes = attributes;
        }
 
        #endregion
 
        #region Implementation
 
        public override void AddItem(int number)
        {
            using (SqlConnection connection = new SqlConnection(this._connectionString))
            {
                using (SqlCommand command = new SqlCommand("AddItem", connection))
                {
                    command.CommandType = CommandType.StoredProcedure;
 
                    command.Parameters.AddWithValue("@Number", number);
 
                    try
                    {
                        connection.Open();
                        command.ExecuteNonQuery();
                        connection.Close();
                    }
                    catch (DataException ex)
                    {
                        // Handle the exception
                        throw ex;
                    }
                    catch (Exception ex)
                    {
                        // Handle the exception
                        throw ex;
                    }
                }
            }
        }
 
        #endregion
    }
}

My database has a single table called SampleTable with ID and Number columns. I used an AddItem stored procedure to add new items to this table.

CREATE PROCEDURE dbo.AddItem
    (
    @Number int
    )
AS
 
INSERT INTO SampleTable
   (Number)
VALUES
   (@Number)
 
RETURN

Configuring the Model

Now it's time to configure the model based on the configuration system that I described in the first part of the series. This is also very easy and simple. I think that seeing the code is the only thing that you need.

<?xml version="1.0"?>
<Sample>
  <Providers>
    <add name="SampleDataProvider" type="ProviderModelSample.Code.SampleSqlDataProvider, ProviderModelSample" />
  </Providers>
</Sample>

Now you see the similarities between this and what you have in built-in .NET providers.

Usage

And the last step is to use this provider model. This is also pretty easy. I create a sample ASP.NET page to use the only method in my provider in order to add a number to the database.

protected void btnAdd_Click(object sender, EventArgs e)
{
    SampleDataProvider provider = SampleDataProvider.Instance();
    provider.AddItem(int.Parse(this.txtNumber.Text));
    this.lblResult.Text = "Number Added.";
}

You see that this is very short and simple. Just create an instance of the abstract class by calling its Instance method and then use its base methods!

Download

Now it's the end of this short post series. I received some feedbacks from readers regarding the usage of built-in .NET classes to achieve same goals. As I stated at the start point and is obvious from the title, this wasn't my goal and I had talked about it in my DotNetSlackers article in enough details. My goal was to build everything from the scratch. This is what many enterprise solutions are doing to achieve a better level of flexibility and reliability. Moreover, knowing these steps, you're able to build a provider model for all versions of the .NET Framework.

You can download a package that contains the full source code sample of this post series and start discovering the code.

Method Type Inference Changes, Part Zero

Eric Lippert — Wed, 28 May 2008 15:16:00 -04:00

Back in November I wrote a bit about a corner case in method type inference which does not work as expected or as specified in C# 3.0. A number of people made blog comments, sent me mail, and entered "Connect" issues with additional problems and ideas for how we could improve this algorithm. (Particular thanks to nikov for his many fascinating and detailed Connect reports.) As a result, as soon as I had time I embarked upon a detailed review of the method type inference specification and the implementation.

The good news is that this resulted in a complete overhaul of both the implementation and the specification; they are now consistent with each other and to the best of my knowledge, correct. Furthermore, the principle concern of commenters on my earlier article has been dealt with: return type inference from a method group to the return type of a delegate type will be legal, but only when the delegate type's input parameters are all completely known. This eliminates the "chicken and egg" problem I discussed in November, whereby overload resolution on the method group must consume the very same unfixed formal parameter types that it is attempting to infer.

The bad news is that these changes to the implementation will not make it in to the service release of C# 3.0; they will have to wait for a later revision of the compiler. (It is not yet clear to me whether or not the changes to the specification will make it into the next edition of the published specification.)

This is one of the most complex areas of the specification and implementation; I'd like to spend some time in this blog going over the specification in detail and explaining where we got things subtly wrong, and how we intend to fix it.

In this series I want to hit on the following points:

What did method type inference look like in C# 2.0? Why was it inadequate for LINQ?
How did we attempt to modify and ultimately rewrite the specification for C# 3.0?
Where did we go subtly wrong in the specification and the implementation?

Next time, we'll get started with a look back at C# 2.0.

Checking out the Source Analysis for C#

Tue, 27 May 2008 22:24:00 -04:00

I've just spent about 30 minutes checking out the recently announced Microsoft Source Analysis for C#. I definitely love the idea, but I'm not sure I'll be using it just yet. Here are some of my impressions (again, I haven't spent a lot of time on it yet)...

All using directives must be placed inside of the namespace

Hmm, but VS itself violates that rule on every class we create...!

The property must not be placed on a single line. The opening and closing curly brackets must each be placed on their own line

Huh? But that an auto-implemented property. What would we want to split that into multiple lines?!

Variable names must not start with 'm_'

Hmpf, that's the standard with have here at the company...

A closing curly bracket must not be preceded by a blank line

Ok, this one I like.

Tabs are not allowed. Use spaces instead

Huh? Thanks, but no, thanks. I've seen a lot of people complaining online about this one too. What's the problem with using tabs??

The call ... must begin with 'this.'...

Ah, I like that one. This is something we've made as part of our guideline here, but couldn't use FxCop to trap for that, since the 'this.' doesn't make into the IL.

Now, the problem here is that, again, the code that VS generates violates this rule all over the place, such as on the example below:

I'll continue to use this tool to see if it's going to stick with me. I've tried it on a very small project, and got 246 violations; the vast majority where produced by code generated by VS. On a big project, I'd probably end up with a LOT more violations, so I'm not sure I can live with that. I believe there is a way to disable some of the rules, but haven't looked for it just yet...

Anyway, I do appreciate Microsoft releasing tools like this one. Hopefully, more and more developers will start paying more attention to how they write code.

How to Build Your Very Own Provider Model - Part 2

Keyvan Nayyeri — Mon, 26 May 2008 13:49:00 -04:00

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.