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.