A Culture of Microcomponents
Friday, May 01 2009 17 Comments
Imagine that you are given the opportunity to rewrite (or upgrade with extreme prejudice) one of your older .NET 2.0 (or 1.1) projects using .NET 3.5. You wrote it, so you have intimate knowledge of the current architecture, what parts smell, what works well. You know what custom components you wrote to solve various problems, etc. You also have a ton of lessons learned. Now you get to do again, only this time you have more advanced, sharper tools at your disposal.
I went through this process recently and came up with no shortage of 3rd party libraries I wanted to use for the new version:
- NHibernate
- Fluent NHibernate
- NHibernate.Linq
- Castle Windsor
- Castle Validators
- log4net
- AutoMapper
- ELMAH
- MvcContrib
- Spark
- jQuery
- jQuery rounded corners
- jQuery auto-complete
- CommonServiceLocator
- LINQ to ActiveDirectory
- docu
- NUnit
- NAnt
This list is nothing to sneeze at, and it's just what I could remember... in fact it's probably a bit longer. This tends to scare people, as it is a lot of stuff to learn. What the heck are these things? Where did they come from? Do I need it? How do I learn it? Why did you include this?
That's a great question. Why do I want to use all of these things?
I firmly believe in leveraging the work of others, and writing code that is expressive and easy to maintain. Some of these projects exist solely to make working with another item from the list a lot easier. NHibernate is a great example. I loves me some NHibernate, but writing XML mapping files by hand isn't what I'd call a fun time. Fluent NHibernate makes this so much nicer. The last thing I want to do is reinvent the wheel.
I don't think I'm alone here. Most projects I come across have a similar attitude regarding re-using rather than re-inventing. Most come with a dozen or so additional libraries so that it can function. I recently asked on twitter how many 3rd party libraries folks are using. The average result was about 5, but some were as high as 12.
The bottom line for me is: The value I get from leveraging 3rd party tools is greater than the psychic weight that they cause. But others may not agree with me.
What about the Ruby community? Don't they have this problem? Absolutely. But I don't think they would classify it as a problem, and I'd tend to agree. Say you're writing a ruby app and you somehow want to integrate flickr with twitter and paypal.
> gem install flickr > gem install twitter > gem install paypal
...Wait what? That's it? Yep. Rubygems is a thing of beauty. It lowers the barrier to installing 3rd party plugins and libraries. Rails plugins has a similar concept. Need to rate one of your models?
script/install plugin acts_as_rateableWant to use jQuery instead of prototype/scriptaculous? simply run
script/install plugin jrails
These techniques allow you to add small pieces of functionality to existing applications with relative ease. You don't have to open a web browser & search for the tool. You don't have to download & extract it somewhere. And you don't need to copy it into your project tree. Everything is done with a single command.
It seems as if every concept and service has their own gem or rails plugin. Rails applications today can be built rather simply by composing tiny pieces of functionality written by other people.
So why can't we do this in .NET? Well in short, we can... but it requires a culture shift. For starters, in .NET we generally check in all of our dependencies into source control, so that we can always guarantee that each developer has all of the required tools (and the specific versions of such tools). With ruby gems, each gem is installed into a common location, which is consistent across all machines (actually it is configurable, but the point is it's a global directory). To use one of the gems installed on your machine, you simply do this:
require 'hpricot'
It knows to load up that library from a central location. When this application is deployed to another environment, the same thing occurs. Gems are installed via the same commands as on the dev machines.
Back at ALT.NET Seattle 2009 I convened a session to discuss revitalizing one of the many gems-for-.NET projects. We identified several efforts along similar lines as gems:
- ngems
- cogs
- nu
- horn
- Machine.PartStore
Out of this discussion, a few folks decided to start fresh with a new project (affectionately called rocks), and toy with getting rubygems to work with IronRuby and wrapping it all in our own command line interface. Not much has been done on this except a quick spike, but I think the idea is promising.
I believe that if something like this comes up in the .NET community it will lead to a shift in how we think about dependencies, components, and overall re-use of small pieces of code to build larger applications.
What do you think?
Chad Myers
5.01.2009
1:31 PM
Yes, sir. Thank you, I'll take 3 :)
Where do we start?