Wednesday, October 22, 2003

Microsoft Application Blocks Not Mature

So, I’ve spent some time over the past couple of weeks looking at Microsoft’s
Application Blocks. If you’re not familiar with these, you should know that
they’re basically software written by the Patterns
& Practices group
that’s aimed at solving common problems. For example,
the Data
Access Application Block
is a set of helper classes aimed at making data access
easier. They’re generally the sort of thing that you write yourself after you’ve
written the same two hundred lines of code three or four times. Only now Microsoft
writes it for you. They even give you the source code.

Unfortunately, as much as I hate to say it, I think these aren’t quite ready
for prime time. I really wanted to like them, not least because I had a nice conversation
with Ron Jacobs from the Patterns & Practices group about them, and he seemed
like a smart, helpful guy. But there are a bunch of little things that just tell me
I’m not likely to get much use from them. Like:

·        The
Data Access Application Block currently only works with SQL Server. You can get bits
from gotdotnet that make it work with Oracle, but it doesn’t do anything to
make the differences between the two databases go away. Not that I necessarily think
they could – but at that point, what value am I getting from the code?

·        The Exception
Management Application Block
only does some of what the Enterprise
Instrumentation Framework
does. Granted, it was written sort of simultaneously
with EIF, but again, where’s the value if there’s something better available?

The really telling ones, though, are things like:

·        The
documentation contains factual errors, claiming at one point that the CLR will load
the assembly with the highest build and revision number where the major and minor
version numbers match the requested version. This was true briefly in one of the betas,
but has never been true in the released CLR.

·        The Configuration
Management Application Block
– which at first looked to be one of the most
useful of the bunch – contains some fairly rookie-type threading bugs.

These last two just kill me. If I’m really going to use this code in my products,
it has to inspire confidence that it was written by someone who knows the problem
domain at least as well as I do. Demonstrating a misunderstanding of the platform
and of basic threading principles don’t achieve that. I emailed the team about
the thread bug, hoping to hear back from them, but it’s been over a week and
nary a word, so here I blog.

That said, I should point out four things. First, that these blocks are the group’s
first attempt, and no one gets anything right on the first try. I expect their next
version will be significantly better. Second, that I didn’t get elbow-deep into
all the blocks, so I might be missing a cool one. Third, that what doesn’t work
for me might work for you. And finally, that the group produces a lot more than just
these blocks, including some fairly decent whitepapers on things like security and team
development with VS.NET
– all stuff I’ve heard my clients beg Microsoft
to do for years. So they’ve moving in the right direction.


  1. I'm glad to read this. I kept thinking that I was being a fool not to embrace them - was I missing the point, was I just being a snotty control freak who like to over architect everything? I come from a VB6 background. VB.NET finally opened SO much up for me to play with. The app blocks just say to me ...nah don't bother.

  2. I agree with both of you. The few I've looked at were either duplicates of something I've already accounted for or far too involved to suit an otherwise simple requirement.

  3. Personally I was pretty impressed with the Blocks. I only looked at the Data Access, Config Mgmt and the User Interface Process block but in my opinion they are much more useful than the sample applications that MS have put out in the past.
    I find sample apps consider just the most basic of cases, these app blocks actually consider realistic scenarios. I had some issues with the User Interface Process block but it was still valuable to me to be able to take a look at how someone else might do it.

  4. I actually do not agree. We have used the data and exception blocks on a couple projects and I have been happy with the results. There is a new version of the Data Access block which does abstract the type of database, so you can use any ADO.NET provider. (Version 3.0, Workspaces)

    There are some errors with the application blocks, but the nice thing is that you can freely modify them since all of the code is included. Could you write something better and more tailored to your situation? Sure, if time was not an issue we would all write everything custom... but for most people the time saved by the application blocks, and the functionality provided, can't be beat.


  5. Well, see now you're killin' me because I'm a Libra - both sides of the argument work for me. I actually talked with Jon Box who had debated on his blog about using them. I emailed him about a month later and said -- SO? And he said he was using them. So methinks, if James Avery and Jon Box are using them....well, that's good enough for me! But I guess for me the point is that even though i'm 150% positive that the folks on the architecture team are way better architects and coders than me :-), I like to construct my own functions and tools for shortcuts. In the long run, it still cuts down my coding time when I use mine. So then is the I think I"m smarter than them? NO of course not. But they are writing something that will cover every base for everyone - lots and lots of code. It's like some of the 3rd party tools (well I guess these are too) that are really bloated so that they can be used in 1000 scenarios. And in the case of the data access block, it still has hole in it - like returning datatables, which I do all of the time. One of those little things people never know - dataadapter fill can fill a datatable. So people using the blocks will never know about this feature. Well - I've said too much already!

  6. On the application blocks as sample code: yes, I agree that they are very well-written when considered as samples...but that's a different standard than the code I put into production sutff.

    On them being better than writing it myself: like I said, your requirements are going to be different than mine. If they work for you, then cool! I, however, was going to wind up spending more time coming through it and guaranteeing correctness than I was replicating the 30% of the block that I actually need. Will I still have to debug my stuff? Yes, but I'll have a comprehensive mental model, and something more suited to exactly what I'm doing.

    So your mileage may vary - just saying what I found for me. :)

  7. Wouldn't you know it - as soon as I posted this, I got an email from the team saying they were looking into the issue. I'll let you all know if they give me any good info.

  8. Hehe.. now the question is.. was that email co-incidence or a really quick response to your post?

  9. You're not paranoid if they really *are* out to get you. :)

    But the email was sent before I posted the blog entry. I just didn't get it until after I got in to work.

  10. Looks like I was wrong on the threading issue:

  11. I have not used Application Blocks, but after dealing with consulting companies & in-house developers who are typically very affected by the environment they are in, App Blocks appear to be a very effective way to understand best practises, & certainly seem to address a need that existed for a long time in MS clientele.

    Frankly, I am never too sure if anyone can get the most universally acceptable code block as every organization has it's nuances of how they will code. In any case, free & open source is certainly winds of change from Redmond :-)

  12. Have any of the errors and shortcoming mentioned above been resolved with the Enterprise Library?

  13. I'm not sure - I haven't had a chance to drill into it enough yet. It's on my to-do list, since we're using the old version at my client, and an upgrade would be a good idea.

  14. Oh, and I should point out again that the threading issue I mention was a misunderstanding on my part - they actually got it quite correct in their implementation.

    FWIW, I've been using the old configuration block for absolutely everything I do at one of my clients. I had to make a few very small modifications, but other than that it has worked really well for us.

  15. Thanks for the head's up Craig. Even though the latest iteration (EntLib) seems to work pretty well for me, I'll throw in a word of caution at the presentation I'm giving to our local .NET User Group this week. Your implied advice, even though it's a bit over a year old, is still valid. Need to keep an eye on it and don't trust it blindly to do everything right.

    Take care,

    Paul Whitaker

  16. Hey thanks for the ongoing thread. By all means please keep us honest. I do hope the Enterprise Library 1 release addresses some concerns. In any case, it is our intent to "open up" the process of EntLib 2 (for VS.NET 2005) to allow for frequent public preview drops, expert advisor concalls. Make us work for you :)

    Wow...What a ride. It's been 1.5 years since Craig submitted this post, an epoch since we started "BlueBricks" and I can tell you I am thrilled to see how more of Microsoft supports and embraces the App Blocks initiative we started in patterns & practices way back then...and I can also tell you that what makes me get up in the morning is your support and of all the community of smart, driven, and good-willing devs like yourselves we work with. If software is all about the people, the app blocks are all about yourselves.

    As long as you keep on demanding and steering and pushing, we'll continue to work hard to provide value... One brick at a time, right?

  17. In talking to prospective programmers for my company and one guy couldn't describe his architecture approach concerning ADO. I was fishing for some feedback about how to handle the dataset to see if this candidate had grasped how simple it had become with ADO.NET. His only answer was that he didn't know what I was talking about because you just pass it to the block and it does everything for you... He didn't get the job. Applications Blocks are good but I would want a programmer to be able to do it himself at least once just as I would like a programmer to be able to code for a control rather than just dropping it on a form and setting it's properties. Who knows? Perhaps someday nobody will know or care what goes on inside the blocks.

  18. I think they should call it "Applications Library". Do not use "Blocks" to fool people. These are nothing new but a bunch of DLLs.