Ron Jacobs

Windows Workflow Foundation

Building Blocks for Everyone

Building Blocks for Everyone

  • Comments 24

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?

  • 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.
  • 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.
  • 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 ( 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.
  • Sorry, I have blogs on the brain - replace blogs with blocks in my comment above and it actually makes sense. =)
  • 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.
  • > 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.

    I would have to disagree here. The V3 DAAB space has not had anything happen for months and there has never really been any Oracle support. There is the start of coding to the interfaces and a liitle bit of Oracle from months and months ago but nothing close to working. On the other hand, I did a brute port to Oracle ODP.NET (sans interfaces) in less than a half a day but not to interfaces. But it doesn't turn outt to be useful and we dropped it. Read ahead.

    Moreover, the DAAB actually is not very useful for two reasons. One is that the level of abstraction is so low that you don't really save that many lines of code. You are almost better how just putting the lines of code that it represents directly in. Two, and most significantly, in COM+/ES applications use of the DAAB is a seriously *bad* pratice. You don't want dozens of stateless JITA objects all blocking on calling one DAAB component to do your database access. In an ES situation (which is 100% of our cases), you want each stateless component to do what it needs to do with data in the component itself as qiucly as possible and get out as it is being instantiated and deleted thousands of times.

    This is in no way to disparage your group's fine efforts as I believe your group is doing some of the best work in the .NET space, parrticularly with your Best Pratices books. I just have problems with the DAAB and actually the Logging Block as well.
  • And a very big +1 on NUnit tests going forward as we use these as a complete arbiter of faith in some code or component that we use and the ability to Refactor it.
  • 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.
  • 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.
  • How to further the development of the application blocks used by many members of the community?
  • Ok - I'll agree that using the DAAB with stateless components does lessen its value. I assume you say this because of the DAAB's parameter cache which is the trick that allows it to invoke stored procedures without having all the parameters defined.

    Once you eliminate that, the DAAB value does decrease because you have to start describing all your parameters again and the lines of code go up.

    ok - maybe I was overstating things a bit when I said that the community effort was a great success. It could be better. The only way a community effort like that succeeds is to have a group of people running the project to insure that it stays active and on track.

    This is something that I would really like to see happen - I'm working on it so stay tuned.
  • 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.

  • I just had an idea.

    How about asking Steve Balmer what he thinks :P
Page 1 of 2 (24 items) 12