Building Blocks for Everyone
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?
Comments
- Anonymous
February 09, 2004
Yes, if NUnit tests were included. The community blocks would have to be as honest and open about their faults or unfinished areas as possible. Finally, the license would be extremely important. - Anonymous
February 09, 2004
I've been pushing my company to adopt the GotDotNet DAAB instead of MS. It makes sense from my perspective because we have applications that connect to multiple datasources. My initial reaction was that I wouldn't get support from MS. However, the GDN code is not hard to understand and it beats writing it myself.
As far as the GDN community extensions - I would like to see better documentation, stress test results (maybe), and of course the NUnit tests are very helpful. - Anonymous
February 09, 2004
I think allowing community involvement in the extension and/or building of the blogs is a great idea. A few suggestions:
1) Maybe you should consider having fewer of the PAG folks doing the development on the blogs and have them act even more as dev leads with the community acting as the developers. This way, you will get direction and guidance (maybe a little review too )from the PAG folks but you can scale the dev effort using the community. Just a thought - maybe a good experiment.
2) Get the Regional Directors, MVPs, and other groups like the ASPInsiders (http://aspinsiders.com) involved in the construction of the application blocks. I think with PAG guidance these groups could apply their "finger on the pulse" connection to the development community and produce some great application blocks.
3) My last suggestion is that you start looking at some of the great features that are being added in Whidbey and build application blocks for v1.x that encompass those features. I know that, in some cases, the reverse had happened (application blocks have manifested into Whidbey features). So, I presume this is possible and would prove to be very useful to those who can't immediately adopt 2.0. - Anonymous
February 09, 2004
Sorry, I have blogs on the brain - replace blogs with blocks in my comment above and it actually makes sense. =) - Anonymous
February 09, 2004
The building blocks are very helpful to the programmers. And I think the best thing is they are open source projects. I've used the Data Access block since last year and made some modification to the block to fit our development. It's really nice. - Anonymous
February 09, 2004
The comment has been removed - Anonymous
February 09, 2004
The comment has been removed - Anonymous
February 09, 2004
While Sam's comments may be spot on for Sam and many "enterprise" developers, there are still thousands of programmers who find benefit in the DAAB in version 3. Not everyone is doing COM/ES applications.
It would be nice to have a higher level of abstraction but I don't see a way to do this with something like the DAAB without it turning into something that understands the objects in the problem domain and this starts to smell of object relational mapping to me.
My two cents. - Anonymous
February 09, 2004
I agree with Sam regarding the use of the DAAB and COM+/ES, as we work on the same code base. As a best practice guideline, I would suggest a disclaimer mentioning problems using the DAAB in distributed environments like ES.
Also, I am very much in favor of including unit tests with the application blocks. I use unit tests religiously, all the way from NUnit tests for my own code, to using unit tests in Rotor code when I port it to another OS. It just makes sense to have tests available to make sure code works, but to also determine where compatability has been broken in order to fix the problems quickly. - Anonymous
February 10, 2004
How to further the development of the application blocks used by many members of the community? - Anonymous
February 10, 2004
The comment has been removed - Anonymous
February 10, 2004
The PAG seems to produce interesting and usefull things.
This propsal to stop doing so strikes me as a case of : If it ain't broke, fix it until it is. - Anonymous
February 10, 2004
I just had an idea.
How about asking Steve Balmer what he thinks :P - Anonymous
February 11, 2004
Just found that MSPetShop v3.0 (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/petshop3x.asp) uses the DAAB, it seems it's a modified version of the "official" but it uses parameters caching and it's intented to be hosted in COM+. The benchmark results are also interesting (http://www.middleware-company.com/documents/j2eedotnetbenchmark.pdf) - Anonymous
February 12, 2004
One more thing. Some people thought that when I said this I was suggesting that we would turn over the entire application blocks program to the community. I'm not suggesting that at all. What I am saying is that there are so many good ideas for blocks out there that our team can never build them all. We need a way to turn the community loose on these ideas that we are not able to build and collaborate with the community in order to build a robust set of blocks, some from Microsoft and some from the community. - Anonymous
February 13, 2004
Rolando -- as I pointed out on the newsgroup, MS PetShop 3.0 only hosts one class and one method in COM+. Not a very compelling case or proof. Plus, they bundle the modified version of the SqlHelper class with the data layer, which is what you would do anyway if you were creating data access library applications in COM+. Again, not very compelling proof, but it is an interesting (and better, in my opinion) approach to use of the DAAB. - Anonymous
February 17, 2004
Cool! MSDN is going to an opensource development model! :) - Anonymous
March 02, 2004
http://dotnetjunkies.com/WebLog/stefandemetz/archive/2004/02/24/7870.aspx