285 days ago I blogged about my dislike for extension methods. Extension methods aren’t very discoverable, and they can lead to poor communication (between members of a team, from project to project, and between a developer and the code he or she is trying to read).
I still think extension methods have serious shortcoming, but I’ve soften my view on them quite a bit. I don’t know what changed, maybe it was my extended foray into Ruby or spending the last few weeks neck-deep in the ASP.NET MVC framework, but I decided to attempt to put out a standard extension library for .NET developers. One of my gripes with extension methods is that they can make projects rather inconsistent, a new developer might be surprised that string.Left suddenly doesn’t work on a new project. Ideally, having a well-known extension library might help solve that problem.
The .NET Extension Library isn’t just about extension methods though. It’s about providing core functionality to projects. For example, I’ve blogged a few times about how hard it is to unit test code that caches – largely because there isn’t an cache interface. This is a problem no more. The .NET Extension Library has an ICache interface, a CacheFactory (which really just returns HttpRuntime.Cache – for now), as well as enhancements to the cache API. Here’s one of my favourite examples of what you can do:
User user = CacheFactory.GetInstance.Fetch(
() => _dataStore.GetUser(userId),
Fetch is a mix between Get and Insert. My second favourite addition are the extensions to IEnumerable, which bring all collections/arrays inline with the List when it comes to methods like Each, TrueForAll, Find, FindAll and more. You no longer need to use the static Array methods.
Input is always welcomed, as are suggestions and/or additions. As much as I’m up for adding useful extension methods, I rather focus on classes that show up in every project kinda thing, such as an abstraction for logging and such.
Anyways, check it out at codeplex: http://www.codeplex.com/nxl