You are here: Home / IT / Daily Developer Dose: DRYing up teh things with an extension method

Daily Developer Dose: DRYing up teh things with an extension method

An extension method for a DRYer way when changing key type of ASP.NET Identity Users and roles

Ah.. extension methods. What a great feature of C#! Making a simple developer feel a bit like a language designer, by adding custom OO style methods to C#’s base types or custom classes.

var now = DateTime.Now;

But of course extension methods are also seen as design smells nowadays. An extension method is a static method which HAS to be in a static class and then prepending the methods’s first parameter with ‘this’:

static class MyExtensions {
public static void ToFunkyDutchDate(DateTime this theDate) {
return string.Format("{0:dd-MM-yyyy}", theDate);

Yikes did I say static? In the modern age of dependency injection and TDD it seems no use of the ‘static’ keyword is allowed anymore. Static fields are bad, because they make your code hard/impossible to test. And extension methods are suffering from ‘feature envy’ according to code masters like Jeff Atwood (though the guy self-admittedly he has no idea what he’s talking about ;).

But if you want to do everything right, things can sometimes turn out to be so much more work initially. Especially when working on an older code base. A lot of the times there is a customer waiting for a fix/feature he/she considers to be simple. But you find a little bug, chase it only to discover a whole heap more. Kind of like Homer Simpson in the intro of this video.

Ofcourse once you’ve cleaned everything up you feel better, and will have to trust it will pay back for itself later. But sometimes it’s better to just take on some technical debt, and leave some TODO’s in your code to refactor things later. So now and then they are just really convenient. Still I sometimes have a hard time with pragmatics like that. My current .NET project is actually brand spanking new, so I would like to keep it clean. Except that it’s based of of the .NET default application, and I have already found out that this standard code actually already contains some code already that is not particularly DRY. I’m using ASP.NET One Identity based on a Code First approach.

Today I changed the key for my (Identity) users from the default GUID to an int, because it just felt better. Microsoft provided a nic eblog post, a nice blog post describing how to di this. It basically comes down to subclassing a whole bunch of of the classes in their Identity NuGet package. However after doing the basic work I was still left with about 40 compile errors of strings that now had to be int:”

The fix in all cases was to change

var userId = User.Identity.GetUserId();


var userId = User.Identity.GetUserId()

Since the `GetUserId()` was already an extension method itself, I decided to write my own. By swapping all uses with that I would only need to change it in this single place, if I later ever decided to change the type again (back to a GUID for instance) :).

using System.Security.Principal;
using Microsoft.AspNet.Identity;

namespace {
public static class IdentityExtensions {
// Central static method to make stuff DRY, so it’s a oneline change in the type of the Identity UserKey is changed again :).
public static int GetUserKey(this IIdentity identity) {
var result = identity.GetUserId();
return result;

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *