I’ve been thinking about application blocks lately. It turns out that of all the things that our team (Patterns & Practices) application blocks seem to be the one thing that people most easily connect with. The problem I have is that there are so many good ideas that could be made into application blocks that our team could never get them all done. The more I thought about this the more I began to wonder if there was some way in which we could turn the community loose on application blocks and let them build their own.
Of course, the community doesn’t really need our permission to do this, however I have found that the community tends to be more active and responsive when we help to organize their efforts a bit. Our first attempt at doing this was with the Data Access Block workspace. We shipped this block with support for SQL Server only, but many of our customers said they wanted to have a version that supported Oracle, OLE-DB or DB2. We took a hard look at this request and decided to give the block to the community and to just let them do it with the hope that the community would extend the block to add this support. So far I would say that the experiment has been a great success.
Now I am thinking of repeating the process with the Caching application block. I have a number of enhancements that I would like to see made to this block and so I am putting together a spec which will guide the community on the development. The question I have in my mind is will people feel comfortable using an application block called “GotDotNet.ApplicationBlock” rather than “Microsoft.ApplicationBlock”.
My feeling is that if the community block included a full suite of NUnit tests that most people would feel comfortable using it. What do you think? Would you feel comfortable using a community block? What blocks would you like to see the community develop?