Question

There’s one specific feature that I wish was in the .NET framework, but isn’t. I wish there were a DBDataReader.GetString (or GetDateTime, GetInt32, etc.) overload that accepted the field name instead of the index. Using the field name makes for easier maintenance IMO, but the GetXxx methods only accept the field position.

I can add these to my project (at least in a limited capacity to suit my immediate needs) by using extension methods, but something about that feels wrong. Beyond the obvious problem that I’d have to repeat this process for every new project, is there any reason not to do what I’m thinking about?

For example, am I headed down a slippery slope of trying to rewrite the framework to suit my whims? Will I leave the poor guy who has to modify my code (probably me) scratching his head trying to figure out what’s going on? Am I violating some core principle of OOP?

Just looking for guidance and viewpoints. Thanks.

Answer 1

This is exactly one of the scenarios extension methods are able to solve. You need functionality that isn’t already available on a type over which you have no control.

As far as duplicating the code in each of your projects, what you need to do is create a class library project to store your common/shared code like this and then either include that project in each Solution and use project references or compile the project, put the resulting assembly in a shared location and include it as a file project reference.

Remeber that extension methods are only available when they are “brought in to scope”. This means that if you have an extension method defined as:

namespace CustomExtensions
{
    public static class StringExtensions
    {
       public static string InvariantToString(this int value)
       {
          return value.ToString(System.Globalization.CultureInfo.InvariantCulture);
       }
    }
}

It will not be visible on any string values unless the code file includes the CustomExtensions namespace with a using directive.

For this reason, it is recommended that you do not put your own extensions in a .NET Framework defined namespace but rather use your own namespace. Doing that minimizes the potential for confusion because your extension won’t be available unless it is explicitly brought in to scope.

Also, keep in mind that if you provide an extension method with the exact same signature as a “built-in” method, your extension method will never be visible or callable – the built-in method always takes precedence. If Microsoft decides to include that functionality in a later version of the Framework and uses the exact same signature you chose then your extension method will no longer be called.

When you define an extension method you aren’t actually redefining the underlying type being extended so you don’t have your own “individual versions”. All an extension method provides is a convenient and more natural way to call a static method in a static class. In fact, using my example extension method above, these are equivalent calls:

int i = 42;
Console.WriteLine(i.InvariantToString());
Console.WriteLine(StringExtensions.InvariantToString(i));

While Microsoft does put a lot of thought in to what to include or not include in the Framework, they have no way of knowing about specific use-cases that might be driving your particular need for certain functionality. Yes, most of the time they do a great job and provide functionality “out of the box” but other times they don’t. (A good example is missing an InvariantToString() method.)